On Mon, May 11, 2009 at 10:41 AM, Justin Deoliveira <[email protected]> wrote: > I am a little confused... the patch does not seem to touch anything related > to id handling. Am I missing something.
Yes; the part where I am stuck on how to patch insert feature writer. > As for null being the placeholder feature id, are you talking about in > ResultSetFeature? What do you want to change it to? Something generated. And then during the write operation (or commit operation?) I want to replace the value inside the FeatureId object; batch feature event holds onto these corrections in a weak hash map in order to allow client code to clean up any feature id filter they are holding. This is coding up in a nicer form the hack Jesse used for WFSDataStore; he passed a filter to WFSDataStore and asked for it to be fixed after a commit. We experimented with the commit method returning a list of generate fids; before deciding that a commit already issues an event - and making use of that event to offer any corrects. > 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. Yes - this is what I want to know. BatchFeatureEvent can be used to communicate the correct value after the fact. Right now you have a "null" released out to client code; and then you update it after the write; can we provide this as the initial value? > 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. Correct; that is what I am trying to do now. It would be nice to get together with you on IRC or something. > And because of this, key generation between multiple transactions will > probably uncover some bugs. I think we can avoid that if the final keys are only assigned during "commit". insert features returns placeholders; which are updated during commit (if we can figure out how?). > 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
