ORM - Single instances of Objects?
I'm working on a small light ORM system for a project. I'm curious as to peoples opinions. If I assume that all database backed objects have a primary key, would you expect a retrieval method by primary key (so the results are guaranteed unique) to return two seperate objects, or references to the same object?
Product product1 = Product.Retrieve(10);
Product product2 = Product.Retrieve(10);
where 10 is the primary key.
Should product1 and product2 be the same object? Or different objects with the same data?
I can see advantages to both (the first means always being sure that the data is up to date anywhere in the system, the second means less worrying about concurrency in multithreaded systems - in some ways...)
Any comments? Thoughts?
January 31st, 2006 11:43am
ORM = Object Role Modelling. It's highjacking pisses me off.
That said. I'd expect the two to be two different references, somewhat similar to having two cursors of the same underlying table. The transactioning of the underlying database should inform the object layer that the data has changed when you write the second back if the first has changed it.
This is all normal. It's primary use would be to have one cursoe open for searches and the other for editing (since typically if you move out of scope on a record it may well be flushed which might not be what you want at all.
Do you have a concept of a session in your system?
Hibernate deals with this quite neatly by guaranteeing that if you ask for twice for an object with the same primary key within the same session you will get the same instance of the object back. If you do the same thing in two different sessions then you get two diffent instances.
January 31st, 2006 12:44pm
Hmm, that sounds interesting - how is a session defined in Hibernate? Is it time or credential based? That doesn't sound that hard to implement...
January 31st, 2006 12:45pm
If they are only representations of something in the db, what does it matter? In preference I would say a single object, but that assumes the data inside the object never changes.
If it does change then I'd prefer a single object until the data changes at which point it becomes two (look at the CString class in MFC which does this, I think). Then when you commit to the db you go back to one object again (okay, this bit might be tricky...).
January 31st, 2006 12:49pm
That's really up to the Hibernate user - the session is pretty much the entry point to Hibernate - all queries and persistence operations are performed via a session and they can be created and destroyed as required by the application.
This section of the Hibernate docs probably explains things better than I can: http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#transactions-basics
January 31st, 2006 12:54pm
If the object could have been deleted, and the key reassigned to a new object between the two calls, then I would expect two different instances of the same object.
I think this is the 'safe' way to go, actually. The "you're querying against the primary key, and ONLY against the primary key" caveat seems awfully limiting. Meaning I would think it would apply to very few queries.
The "any query gives you a new instance of the result set" approach seems much more general.
January 31st, 2006 2:09pm