db4o object update dilemma

I am new to db4o.

I have this question in mind: when the object are retrieved from DAL, maybe it will update in Business layer, then we lost it's original property, so when it comes to updating how can I find which one is the original object in the database to update?

From stackoverflow

• You should load the object via its ID:

  objectContainer.get().ext().getByID(id);
  

  or via its UUID:

  objectContainer.get().ext().getByUUID(uuId);
  

  See the docs for the latter one. For an explanation see the answer here or the docs here. In short use uuid only for long term referencing.

  Benny : then i will have to store the ID of the object retrieved from db somewhere?

  Karussell : hmmh, yes. I don't know of the architecture you are using but typically the ids are stored in the session instead of the entire object and the objects are loaded again from its id on the next request. But as mnemosyn already pointed out: you typically won't need ids as long as you reference to the same object (db4o will then do the update). Maybe you can give us some code with the problems you have.

  Benny : @Karussell, as mnemosyn pointed out, as long as the object instance and the ObjectContainer instance are the same one, the object update is easy, so, is this mean i need keep the database open during the life time of my app? then this is so different from the way we use RDBMS, coz, RDBMS normally only open the database for CRUD, and close it right away.

  Karussell : sorry, I don't understand what you mean and need :-( you don't need to let the db-container open. the id will always be the same (as long as you don't do a defragmentation). So you can open an instance in different container - the instance will have the same id in both containers! you can use db4o nearly in the same way as e.g. hibernate. Apply the popular session per request pattern. Some days ago I created an example with db4o+wicket+guice: http://karussell.wordpress.com/2010/01/18/crud-with-wicket-guice-db4o-neodatis/ hopefully that will take you further to a solution :-)

• You need to be more precise about "the object". If you modify the object instance's properties, simply storing it again will perform an update:

  MyClass someInstance = ObjectContainer.Query<MyClass>().FirstOrDefault();
  someInstance.Name = "NewName";
  someInstance.PhoneNumber = 12132434;
  ObjectContainer.Store(someInstance); // This is the update call
  

  [This is just pseudo-code]

  So you don't need to match objects to each other as you would have to when using an RDBMS.

  However, you need to make sure you are not using a different instance of ObjectContainer, because a different container will not know these objects are the same instance (since there is no ID field in them).

  Your application architecture should help to do this for most workflows, so there should be really only one IObjectContainer around. Only if timespans are really long (e.g. you need to store a reference to the object in a different database and process it somehow) it'd use the UUID. AS you already pointed out, that requires to store the ID somewhere else and hence complexifies your architecture.

  If you however intend to create a new object and 'overwrite' the old object, things get somewhat more complicated because of other objects that might refer to it. However, this is a somehwat pathological case and should typically be handled within the domain model itself, e.g. by copying object data from one object to another.

  Benny : so, are you suggesting that i keep the database open during the running of the application so that i will only have one instance of ObjectContainer?

  mnemosyn : Essentially, yes. The idea is that the ObjectContainer is responsible for keeping object identities. Therefore, whenever you close a container you lose that information. In contrast to typical RDBMS, where you open/close connections as quick as possible, db4o containers should remain open all the time you potentially need access to your data model. In a web application, for example, you would open the connection upon request begin and close it when the request is completed. In a desktop application, you might want to keep the instance open even longer. Note that it keeps references!