Justin Deoliveira ha scritto: > I am a little confused... the patch does not seem to touch anything > related to id handling. Am I missing something. > > As for null being the placeholder feature id, are you talking about in > REsultSetFeature? What do you want to change it to? > > Id generation is a bit tricky. The way it is done now is actually not > ideal. The problem lies in that the datastore tries to figure out the ID > before it tries to commit, which is really just wrong, the only truly > reliable way is to task for it after the fact. But that is hard to do in > this case because DataStore.insertFeatures needs to report back the > fids. Sort of a problem with the api. I seem to remember you having an > idea about how to get around this.... I think it was with events.
I still don't see why we need to get the ids _after_, can anybody enlighten me? From what I know, both in the case of sequences and serial keys the value is generated right away when you insert, and if the transaction fails, the value is simply lost. Hibernate does always generate the keys before insertion, I don't know any tool doing otherwise since "serial" types are not very common and the standard "getGeneratedKeys" request that would allow one to retrieve the values after they are generated (right after the insert anyways, never at the commit) is not implemented or properly working in a number of databases. See http://docs.jboss.org/hibernate/stable/core/reference/en/html/mapping.html#mapping-declaration-id for information on how Hibernate does generate the pk fields, and Also see this: http://docs.jboss.org/hibernate/stable/core/reference/en/html/objectstate-makingpersistent.html to confirm that Hibernate returns the ids right away when an object is saved, not when the connection is committed. > And because of this, key generation between multiple transactions will > probably uncover some bugs. As long as reliable ways to generate a key are used (sequences, serials, UUID) this won't happen (I mean, it won't happen due to getting keys before the connection is committed, other causes might cause a bug to trigger). Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
