Entity rework

[kenjis]

Description
Fixes#5905
Supersedes #6284

• Now all Entity::$attributes have (cast) PHP values, not raw values from database
• add CastInterface::toDatabase() and CastInterface::fromDatabase()
• add Entity::toDatabase() to return array for database and Entity::fromDatabase() to rebuild Entity from database data

[App Code] --- set() --> [Entity] --- toDatabase() ---> [Database]
[App Code] <-- get() --- [Entity] <-- fromDatabase() -- [Database]

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

@samsonasik Probably get_class($entity) causes the Rector error:

 [ERROR] Could not process "tests/system/Entity/EntityLiveTest.php" file, due to: "assert(count($exprType) === 1)". On line: 170 

Do you know something?

[MGatner]

I fear this is leaning into the issue from last time. Most of the handling is correct but I would argue it is in the wrong place. We keep tying our data representations to the actual database driver. This does move the responsibility off of Entity (somewhat) but now bakes those assumptions into Cast.

What about NoSQL databases? in-memory mocks? entities bound for API endpoints? Why should they all be bound to MySQL's limitations?

Single responsibility: let Entity hold the data and represent the object, let Cast convert between different data types and act as a gate for bad data, let Model send associative arrays of data back and forth from storage.

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions. The problem is that BaseModel/Model is already a mess, and we've pushed most of our driver-specific implementation into the Query Builders.

[kenjis]

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions.

let Model send associative arrays of data back and forth from storage.

Do you mean Model should have logic for toDatabase() and fromDatabase()?

CI's QueryBuilder has the feature to use Custom Result Objects:
https://codeigniter4.github.io/CodeIgniter4/database/results.html#getcustomresultobject
If Model has the data conversion logic, QueryBuilder can't use it when it creates an Entity.
Do you say we should make the feature deprecated?

[MGatner]

@kenjis I'm afraid I don't have good answers, only concerns. I believe the current architecture is bad, and the mess of our code between entity-model-builder shows for it. Every time an issue or feature comes up and we commit more to this architecture I get worried we are digging ourselves in deeper. But the reality is that we can't afford a complete refactor right now, nor could we even release it (except maybe as a standalone).

For the issue at hand: if we can find a way to let Model (SQL-specific) handle to/from database I think that's the best place for the new code to reside, architecturally speaking.

[kenjis]

Description
Fixes#5905
Supersedes #6284

• Now all Entity::$attributes have (cast) PHP values, not raw values from database
• add CastInterface::toDatabase() and CastInterface::fromDatabase()
• add Entity::toDatabase() to return array for database and Entity::fromDatabase() to rebuild Entity from database data

[App Code] --- set() --> [Entity] --- toDatabase() ---> [Database]
[App Code] <-- get() --- [Entity] <-- fromDatabase() -- [Database]

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

@samsonasik Probably get_class($entity) causes the Rector error:

 [ERROR] Could not process "tests/system/Entity/EntityLiveTest.php" file, due to: "assert(count($exprType) === 1)". On line: 170 

Do you know something?

[MGatner]

I fear this is leaning into the issue from last time. Most of the handling is correct but I would argue it is in the wrong place. We keep tying our data representations to the actual database driver. This does move the responsibility off of Entity (somewhat) but now bakes those assumptions into Cast.

What about NoSQL databases? in-memory mocks? entities bound for API endpoints? Why should they all be bound to MySQL's limitations?

Single responsibility: let Entity hold the data and represent the object, let Cast convert between different data types and act as a gate for bad data, let Model send associative arrays of data back and forth from storage.

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions. The problem is that BaseModel/Model is already a mess, and we've pushed most of our driver-specific implementation into the Query Builders.

[kenjis]

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions.

let Model send associative arrays of data back and forth from storage.

Do you mean Model should have logic for toDatabase() and fromDatabase()?

CI's QueryBuilder has the feature to use Custom Result Objects:
https://codeigniter4.github.io/CodeIgniter4/database/results.html#getcustomresultobject
If Model has the data conversion logic, QueryBuilder can't use it when it creates an Entity.
Do you say we should make the feature deprecated?

[MGatner]

@kenjis I'm afraid I don't have good answers, only concerns. I believe the current architecture is bad, and the mess of our code between entity-model-builder shows for it. Every time an issue or feature comes up and we commit more to this architecture I get worried we are digging ourselves in deeper. But the reality is that we can't afford a complete refactor right now, nor could we even release it (except maybe as a standalone).

For the issue at hand: if we can find a way to let Model (SQL-specific) handle to/from database I think that's the best place for the new code to reside, architecturally speaking.

[kenjis]

Description
Fixes#5905
Supersedes #6284

• Now all Entity::$attributes have (cast) PHP values, not raw values from database
• add CastInterface::toDatabase() and CastInterface::fromDatabase()
• add Entity::toDatabase() to return array for database and Entity::fromDatabase() to rebuild Entity from database data

[App Code] --- set() --> [Entity] --- toDatabase() ---> [Database]
[App Code] <-- get() --- [Entity] <-- fromDatabase() -- [Database]

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

@samsonasik Probably get_class($entity) causes the Rector error:

 [ERROR] Could not process "tests/system/Entity/EntityLiveTest.php" file, due to: "assert(count($exprType) === 1)". On line: 170 

Do you know something?

[MGatner]

I fear this is leaning into the issue from last time. Most of the handling is correct but I would argue it is in the wrong place. We keep tying our data representations to the actual database driver. This does move the responsibility off of Entity (somewhat) but now bakes those assumptions into Cast.

What about NoSQL databases? in-memory mocks? entities bound for API endpoints? Why should they all be bound to MySQL's limitations?

Single responsibility: let Entity hold the data and represent the object, let Cast convert between different data types and act as a gate for bad data, let Model send associative arrays of data back and forth from storage.

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions. The problem is that BaseModel/Model is already a mess, and we've pushed most of our driver-specific implementation into the Query Builders.

[kenjis]

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions.

let Model send associative arrays of data back and forth from storage.

Do you mean Model should have logic for toDatabase() and fromDatabase()?

CI's QueryBuilder has the feature to use Custom Result Objects:
https://codeigniter4.github.io/CodeIgniter4/database/results.html#getcustomresultobject
If Model has the data conversion logic, QueryBuilder can't use it when it creates an Entity.
Do you say we should make the feature deprecated?

[MGatner]

@kenjis I'm afraid I don't have good answers, only concerns. I believe the current architecture is bad, and the mess of our code between entity-model-builder shows for it. Every time an issue or feature comes up and we commit more to this architecture I get worried we are digging ourselves in deeper. But the reality is that we can't afford a complete refactor right now, nor could we even release it (except maybe as a standalone).

For the issue at hand: if we can find a way to let Model (SQL-specific) handle to/from database I think that's the best place for the new code to reside, architecturally speaking.

[kenjis]

Description
Fixes#5905
Supersedes #6284

• Now all Entity::$attributes have (cast) PHP values, not raw values from database
• add CastInterface::toDatabase() and CastInterface::fromDatabase()
• add Entity::toDatabase() to return array for database and Entity::fromDatabase() to rebuild Entity from database data

[App Code] --- set() --> [Entity] --- toDatabase() ---> [Database]
[App Code] <-- get() --- [Entity] <-- fromDatabase() -- [Database]

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

@samsonasik Probably get_class($entity) causes the Rector error:

 [ERROR] Could not process "tests/system/Entity/EntityLiveTest.php" file, due to: "assert(count($exprType) === 1)". On line: 170 

Do you know something?

[MGatner]

I fear this is leaning into the issue from last time. Most of the handling is correct but I would argue it is in the wrong place. We keep tying our data representations to the actual database driver. This does move the responsibility off of Entity (somewhat) but now bakes those assumptions into Cast.

What about NoSQL databases? in-memory mocks? entities bound for API endpoints? Why should they all be bound to MySQL's limitations?

Single responsibility: let Entity hold the data and represent the object, let Cast convert between different data types and act as a gate for bad data, let Model send associative arrays of data back and forth from storage.

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions. The problem is that BaseModel/Model is already a mess, and we've pushed most of our driver-specific implementation into the Query Builders.

[kenjis]

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions.

let Model send associative arrays of data back and forth from storage.

Do you mean Model should have logic for toDatabase() and fromDatabase()?

CI's QueryBuilder has the feature to use Custom Result Objects:
https://codeigniter4.github.io/CodeIgniter4/database/results.html#getcustomresultobject
If Model has the data conversion logic, QueryBuilder can't use it when it creates an Entity.
Do you say we should make the feature deprecated?

[MGatner]

@kenjis I'm afraid I don't have good answers, only concerns. I believe the current architecture is bad, and the mess of our code between entity-model-builder shows for it. Every time an issue or feature comes up and we commit more to this architecture I get worried we are digging ourselves in deeper. But the reality is that we can't afford a complete refactor right now, nor could we even release it (except maybe as a standalone).

For the issue at hand: if we can find a way to let Model (SQL-specific) handle to/from database I think that's the best place for the new code to reside, architecturally speaking.

[kenjis]

Description
Fixes#5905
Supersedes #6284

• Now all Entity::$attributes have (cast) PHP values, not raw values from database
• add CastInterface::toDatabase() and CastInterface::fromDatabase()
• add Entity::toDatabase() to return array for database and Entity::fromDatabase() to rebuild Entity from database data

[App Code] --- set() --> [Entity] --- toDatabase() ---> [Database]
[App Code] <-- get() --- [Entity] <-- fromDatabase() -- [Database]

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

@samsonasik Probably get_class($entity) causes the Rector error:

 [ERROR] Could not process "tests/system/Entity/EntityLiveTest.php" file, due to: "assert(count($exprType) === 1)". On line: 170 

Do you know something?

[MGatner]

I fear this is leaning into the issue from last time. Most of the handling is correct but I would argue it is in the wrong place. We keep tying our data representations to the actual database driver. This does move the responsibility off of Entity (somewhat) but now bakes those assumptions into Cast.

What about NoSQL databases? in-memory mocks? entities bound for API endpoints? Why should they all be bound to MySQL's limitations?

Single responsibility: let Entity hold the data and represent the object, let Cast convert between different data types and act as a gate for bad data, let Model send associative arrays of data back and forth from storage.

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions. The problem is that BaseModel/Model is already a mess, and we've pushed most of our driver-specific implementation into the Query Builders.

[kenjis]

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions.

let Model send associative arrays of data back and forth from storage.

Do you mean Model should have logic for toDatabase() and fromDatabase()?

CI's QueryBuilder has the feature to use Custom Result Objects:
https://codeigniter4.github.io/CodeIgniter4/database/results.html#getcustomresultobject
If Model has the data conversion logic, QueryBuilder can't use it when it creates an Entity.
Do you say we should make the feature deprecated?

[MGatner]

@kenjis I'm afraid I don't have good answers, only concerns. I believe the current architecture is bad, and the mess of our code between entity-model-builder shows for it. Every time an issue or feature comes up and we commit more to this architecture I get worried we are digging ourselves in deeper. But the reality is that we can't afford a complete refactor right now, nor could we even release it (except maybe as a standalone).

For the issue at hand: if we can find a way to let Model (SQL-specific) handle to/from database I think that's the best place for the new code to reside, architecturally speaking.

[kenjis]

Description
Fixes#5905
Supersedes #6284

• Now all Entity::$attributes have (cast) PHP values, not raw values from database
• add CastInterface::toDatabase() and CastInterface::fromDatabase()
• add Entity::toDatabase() to return array for database and Entity::fromDatabase() to rebuild Entity from database data

[App Code] --- set() --> [Entity] --- toDatabase() ---> [Database]
[App Code] <-- get() --- [Entity] <-- fromDatabase() -- [Database]

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

@samsonasik Probably get_class($entity) causes the Rector error:

 [ERROR] Could not process "tests/system/Entity/EntityLiveTest.php" file, due to: "assert(count($exprType) === 1)". On line: 170 

Do you know something?

[MGatner]

I fear this is leaning into the issue from last time. Most of the handling is correct but I would argue it is in the wrong place. We keep tying our data representations to the actual database driver. This does move the responsibility off of Entity (somewhat) but now bakes those assumptions into Cast.

What about NoSQL databases? in-memory mocks? entities bound for API endpoints? Why should they all be bound to MySQL's limitations?

Single responsibility: let Entity hold the data and represent the object, let Cast convert between different data types and act as a gate for bad data, let Model send associative arrays of data back and forth from storage.

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions. The problem is that BaseModel/Model is already a mess, and we've pushed most of our driver-specific implementation into the Query Builders.

[kenjis]

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions.

let Model send associative arrays of data back and forth from storage.

Do you mean Model should have logic for toDatabase() and fromDatabase()?

CI's QueryBuilder has the feature to use Custom Result Objects:
https://codeigniter4.github.io/CodeIgniter4/database/results.html#getcustomresultobject
If Model has the data conversion logic, QueryBuilder can't use it when it creates an Entity.
Do you say we should make the feature deprecated?

[MGatner]

@kenjis I'm afraid I don't have good answers, only concerns. I believe the current architecture is bad, and the mess of our code between entity-model-builder shows for it. Every time an issue or feature comes up and we commit more to this architecture I get worried we are digging ourselves in deeper. But the reality is that we can't afford a complete refactor right now, nor could we even release it (except maybe as a standalone).

For the issue at hand: if we can find a way to let Model (SQL-specific) handle to/from database I think that's the best place for the new code to reside, architecturally speaking.

[kenjis]

Description
Fixes#5905
Supersedes #6284

• Now all Entity::$attributes have (cast) PHP values, not raw values from database
• add CastInterface::toDatabase() and CastInterface::fromDatabase()
• add Entity::toDatabase() to return array for database and Entity::fromDatabase() to rebuild Entity from database data

[App Code] --- set() --> [Entity] --- toDatabase() ---> [Database]
[App Code] <-- get() --- [Entity] <-- fromDatabase() -- [Database]

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

@samsonasik Probably get_class($entity) causes the Rector error:

 [ERROR] Could not process "tests/system/Entity/EntityLiveTest.php" file, due to: "assert(count($exprType) === 1)". On line: 170 

Do you know something?

[MGatner]

I fear this is leaning into the issue from last time. Most of the handling is correct but I would argue it is in the wrong place. We keep tying our data representations to the actual database driver. This does move the responsibility off of Entity (somewhat) but now bakes those assumptions into Cast.

What about NoSQL databases? in-memory mocks? entities bound for API endpoints? Why should they all be bound to MySQL's limitations?

Single responsibility: let Entity hold the data and represent the object, let Cast convert between different data types and act as a gate for bad data, let Model send associative arrays of data back and forth from storage.

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions. The problem is that BaseModel/Model is already a mess, and we've pushed most of our driver-specific implementation into the Query Builders.

[kenjis]

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions.

let Model send associative arrays of data back and forth from storage.

Do you mean Model should have logic for toDatabase() and fromDatabase()?

CI's QueryBuilder has the feature to use Custom Result Objects:
https://codeigniter4.github.io/CodeIgniter4/database/results.html#getcustomresultobject
If Model has the data conversion logic, QueryBuilder can't use it when it creates an Entity.
Do you say we should make the feature deprecated?

[MGatner]

@kenjis I'm afraid I don't have good answers, only concerns. I believe the current architecture is bad, and the mess of our code between entity-model-builder shows for it. Every time an issue or feature comes up and we commit more to this architecture I get worried we are digging ourselves in deeper. But the reality is that we can't afford a complete refactor right now, nor could we even release it (except maybe as a standalone).

For the issue at hand: if we can find a way to let Model (SQL-specific) handle to/from database I think that's the best place for the new code to reside, architecturally speaking.

[kenjis]

Description
Fixes#5905
Supersedes #6284

• Now all Entity::$attributes have (cast) PHP values, not raw values from database
• add CastInterface::toDatabase() and CastInterface::fromDatabase()
• add Entity::toDatabase() to return array for database and Entity::fromDatabase() to rebuild Entity from database data

[App Code] --- set() --> [Entity] --- toDatabase() ---> [Database]
[App Code] <-- get() --- [Entity] <-- fromDatabase() -- [Database]

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

@samsonasik Probably get_class($entity) causes the Rector error:

 [ERROR] Could not process "tests/system/Entity/EntityLiveTest.php" file, due to: "assert(count($exprType) === 1)". On line: 170 

Do you know something?

[MGatner]

I fear this is leaning into the issue from last time. Most of the handling is correct but I would argue it is in the wrong place. We keep tying our data representations to the actual database driver. This does move the responsibility off of Entity (somewhat) but now bakes those assumptions into Cast.

What about NoSQL databases? in-memory mocks? entities bound for API endpoints? Why should they all be bound to MySQL's limitations?

Single responsibility: let Entity hold the data and represent the object, let Cast convert between different data types and act as a gate for bad data, let Model send associative arrays of data back and forth from storage.

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions. The problem is that BaseModel/Model is already a mess, and we've pushed most of our driver-specific implementation into the Query Builders.

[kenjis]

Since Model is the only class that actually cares about the infrastructure: it should handle any necessary data conversions.

let Model send associative arrays of data back and forth from storage.

Do you mean Model should have logic for toDatabase() and fromDatabase()?

CI's QueryBuilder has the feature to use Custom Result Objects:
https://codeigniter4.github.io/CodeIgniter4/database/results.html#getcustomresultobject
If Model has the data conversion logic, QueryBuilder can't use it when it creates an Entity.
Do you say we should make the feature deprecated?

[MGatner]

@kenjis I'm afraid I don't have good answers, only concerns. I believe the current architecture is bad, and the mess of our code between entity-model-builder shows for it. Every time an issue or feature comes up and we commit more to this architecture I get worried we are digging ourselves in deeper. But the reality is that we can't afford a complete refactor right now, nor could we even release it (except maybe as a standalone).

For the issue at hand: if we can find a way to let Model (SQL-specific) handle to/from database I think that's the best place for the new code to reside, architecturally speaking.