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. And because of this, key generation between multiple transactions will probably uncover some bugs. Jody Garnett wrote: > Justin I need a code review on the feature id handling; and the > handling of commit prior to this patch being acceptable to me: > > 1) BatchFeatureEvent should be notified of any change to FeatureId; > right now you are using null as an ID placeholder and I would like to > change that. I also wanted to ask about the handling of ID generation > when two transactions are going at once? > > 2) Commit / Revert are handled by a TransactionState; one transaction > state for each featureType involved in the transaction; as such each > transaction state will issue a commit on the connect. I would like to > change this so that: > a) a single transaction state is assigned to the connection > b) batch feature event moves into the transaction state for the connection > > It sounds like aggregate functions are the next thing needed to wrap > up the jdbc-ng work; did you want me to add to the dialect classes or > did you want to allow a generic sql call? > > Jody > > On Mon, May 11, 2009 at 8:52 AM, Justin Deoliveira <[email protected]> > wrote: >> Cool, just reviewed and made some comments on the jira issue. >> >> -Justin >> >> Jody Garnett wrote: >>> Hi Justin: >>> >>> There is a patch ready for your review: >>> - http://jira.codehaus.org/browse/GEOT-2327 >>> >>> There is some additional work that could be done if interested; right >>> now a batch feature event is sent out on commit or rollback - one for >>> each feature type modified. This is a bit over kill; a single batch >>> feature event can be sent out; but I would need to register that with >>> the connection. Indeed right now it looks like commit is called twice >>> by your code? once for each feature type? >>> >>> If I am missing something here please let me know. >>> Jody >> >> -- >> Justin Deoliveira >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >> -- 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
