Andrea Aime wrote: > 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?
Well on an insert you have to report back the FID no? So the options are try to figure it what it will be before hand, or ask the db what it was after. The first is tough because auto generation is not standard across db's. And even if it were, asking the serial for its current value, then doing an insert assumes you have exclusive access, which is why there is a synchronized call surrounding that part of the code. And as you stated the later does not work, since getGeneratedKeys() is not properly implemented. > > 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). OK... still seems like there is the possibility for a race condition to occur with two writers committing to the same connection. But maybe i am missing something. I delegate to the db expert on this one :) > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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
