Hi all, Thanks for your insights and all these comments.
I'd love to do option #2 but this is something we can not do as the project I'm working on should not have any impact on the underlying applications except the application which exposes the model and discusses with the storage. I can't do option #1 as it the aim of the project... ;) I think we'll _just_ need to integrate the handling of the incremented IDs in the application we're re-writing (searching for the next available id and then insert the entry once we've figured out what value to use). The idea is also to keep the existing API for compatibility reasons, but deprecate a few elements in the model and additionally provide a *cleaner* API that applications could use for a future migration. Pierre-Arnaud On Wed, Jan 14, 2009 at 7:54 AM, David Boreham <[email protected]>wrote: > Emmanuel Lecharny wrote: > >> The thing is that Pierre-Arnaud is moving away from a RDBMS system ;) But >> the applications are using Integers and Longs for IDs... >> > Right, and I'd say either 1) Don't move from the RDBMS, or 2) Change the > applications to not expect integers. > > Do not do 3) : attempt to make the DS behave like the RDBMS. > > > > > >
