3 ms·

I think you misunderstand the identity issue. I think its more a complaint about mutating objects not cleanly mapping to running UPDATE commands. Live objects

by jayd16 6y ago

I think you misunderstand the identity issue. I think its more a complaint about mutating objects not cleanly mapping to running UPDATE commands. Live objects and partial updates are messy and dirty writes become an issue. I often see a a pattern of a Save() method on an ORM type and its ambiguous as to what exactly that will write to the DB at any time. Maybe there are better ORM patterns but the problem is its a common anti-pattern none the less. If you use a more RPC approach to your data layer, partial updates based on an entity id are easier to groc.

tehlike 6y ago
I think I understood correct "When you have foreign keys, you refer to related identities with an identifier." "What this results in is having to manipulate the ORM to get a database identifier by manually flushing the cache or doing a partial commit to get the actual database identifier." This(and the sentences before it) basically saying if you have if you have a foreign key you have to first save the main object to get it's id. Id doesn't have to be responsibility of the database. In fact, I'd argue an identifier is an application layer concern. Orm could still solve this problem by simply cascading, or you can use one of the identity strategies that don't rely on database assigning it. You can generate them in either application layer or orm layer through identity generators.
- jayd16 6y ago
  Let me be more clear. Partial objects, such as a book with an author created from a user request may or may not have DB ids that may or may not exist. If you want to add a Book object with an Author you must first upsert the Author to possibly retrieve the DB id which already exists and cannot simply be generated locally. This can often be a bit confusing or cumbersome compared to the SQL. Why are you caring about DB ids if the ORM is supposed to handle it, asks OP.

by jayd16 6y ago

tehlike 6y ago

I think I understood correct "When you have foreign keys, you refer to related identities with an identifier." "What this results in is having to manipulate the ORM to get a database identifier by manually flushing the cache or doing a partial commit to get the actual database identifier." This(and the sentences before it) basically saying if you have if you have a foreign key you have to first save the main object to get it's id. Id doesn't have to be responsibility of the database. In fact, I'd argue an identifier is an application layer concern. Orm could still solve this problem by simply cascading, or you can use one of the identity strategies that don't rely on database assigning it. You can generate them in either application layer or orm layer through identity generators.

jayd16 6y ago
Let me be more clear. Partial objects, such as a book with an author created from a user request may or may not have DB ids that may or may not exist. If you want to add a Book object with an Author you must first upsert the Author to possibly retrieve the DB id which already exists and cannot simply be generated locally. This can often be a bit confusing or cumbersome compared to the SQL. Why are you caring about DB ids if the ORM is supposed to handle it, asks OP.