This project is read-only.

Replace object by OID?

Apr 30, 2013 at 5:54 PM
Suppose I have an application with a central database that contains Tools and Ingredients. Also suppose the application wants to export a new database file containing a Recipe.

Recipe instances can refer to Tools and Ingredients. When I export a Recipe, I also export all of the Tools and Ingredients it uses. Later, when I want to import that Recipe, I bring in the Tools and Ingredients and go through a reconciliation process to match up Tools and Ingredients in the Recipe with those in the central database.

The output of the reconciliation process is a mapping from instances in the Recipe to instances in the central database (I may have created new instances in the central database as well, as part of creating this mapping.)

What I want to do now is go through the Recipe instance (and everything it uses), replacing any references to Tools and Ingredients with the mapped instances in the central database. I can write code to do this by hand (hard-coding all the logic to search and update the references), but it would be very convenient if there were some way to 'replace' an object instance in the database. I have the OID of the original instance that has been mapped, so what I'd like is a way to make that OID point to a new instance (replacing the entire content of an object in the database.) I would then want to grab a fresh copy of the Recipe instance. By virtue of having replaced the objects (but keeping the OID the same), the Recipe would point to the new instances.

Is this something that would be straightforward to do? I would be okay with cached instances having stale references (i.e. any instances we already retrieved when not be updated automatically), as I would likely want to re-open the database file anyway before performing the mapping.
May 3, 2013 at 9:01 PM
Hello,
what about updating the existing objects? So if you now the OID, you could retrieve the object from db and update its state with new one (own updater class or update method to do the work for you), what do you think?

Thanks,
Jacek
May 3, 2013 at 9:36 PM
I'm currently doing the updating manually (using a series of methods that walk through the various parts of the loaded Recipe to re-direct the references to the central database instances.) This works reasonably well, but it means that I need to modify the Update methods whenever the structure of the Recipe changes.

My idea was to use the database to handle this for me, because the database already maintains an intermediate mapping from OIDs to instances. If I can specify that OIDs 'redirect' to a new particular instance, I can take advantage of this OID mapping to perform my own instance->instance mapping for reconciliation purposes.

Thinking of it in this way, one possible implementation would be to have an 'Override' table option that you can specify to override the normal OID to object resolution. I imagine it working like this:
  1. User would first pass in a Dictionary<OID, object> providing the mapping.
  2. The database, when creating an instance from an OID, would first check this override mapping dictionary. If it finds it there, it uses that instance. Otherwise it goes to the database as normal.
I think this would be extremely useful for these kind of "Import"/"Export" scenarios. The procedure would be like this:
  1. Open a Recipe database and get all of its Ingredients/Tools.
  2. Reconcile these Ingredients/Tools to the main database (this is application-specific code) to come up with the mapping to the central database instances.
  3. Open the Recipe database again, but now use the mapping created from (2) to get a Recipe instance that has its references mapped to the central database. This means that none of the Ingredients/Tools would actually come from the Recipe database in this case; they would all end up being pulled from the OID override
    mapping.
  4. Now I can store the new Recipe into the central database and all of its references are properly pointing to instances in that database.
Basically we've 'merged' the databases, using application-specific rules to resolve conflicts.
May 12, 2013 at 5:55 PM
Hello, release NDatabase 3.8 is helping to map internal OID to your classes fields, maybe that could simplify your solution.

Regards,
Jacek