Menu
▾
▴
Re: [Geotools-devel] GEOT-728, fix and refactor FIDMapper classes
|
From: Michael B. <mi...@lu...> - 2006-07-11 14:14:10
|
Up until about a month ago the FIDs generated by AutoIncrementFIDMapper were always null. So I would be a bit surprised if making it abstract broke anything that wasn't already broken... In regards to the example, the problem occurs because the database column actually is autoincrementing -- i.e. the DB has an internal record of what the next value should be, and it is not always the same as the value returned by SELECT MAX(ID). (the internal record increases on inserts but doesn't decrease on deletes, if that makes sense? I think PostGIS sequence values are the same?) Michael On Jul 11, 2006, at 7:00 PM, David Adler wrote: > The FIDMapper classes have also caused me considerable aggravation. > > I had to subclass AutoIncrementFIDMapper for DB2 in part because > each table name needs to be > qualified by the schema name. > > Does anyone use AutoIncrementFIDMapper as it currently exists? If > it changes to abstract, what will it break? > > It isn't clear to me why the MySQL problem illustrated below > occurs. If you add > ID 100 delete it and do a SELECT MAX(ID), shouldn't it again return > 100? > > At 10:43 AM 7/10/2006, Michael Brasser wrote: >> Hi David, >> >> Just wanted to mention that there was some discussion on the list >> about a month ago about refactoring AutoIncrementFIDMapper. It >> currently uses "order by" to return a value, but this is problematic >> (I've included a problem case from the earlier discussion below). Not >> sure if it would make sense to (or if you would even be willing to) >> look at this issue while you are working with the FIDMapper code? >> >> Regards, >> Michael >> >> On June 7, 2006, Michael Brasser wrote: >> >> > I also like your suggestion for making AutoIncrementFIDMapper >> > abstract (with subclasses for specific datastores). One potential >> > problem with the current "...order by..." solution is the following >> > case (which I have verified in MySQL): >> > >> > a. We already have 99 records, IDs 1-99 >> > b. Add a new record, automatically generated ID is 100 >> > c. Delete the newly added record. >> > d. Add another new record, automatically generated ID is 101, but >> > "SELECT MAX" and "ORDER BY" would both cause the feature id >> mapper to >> > return 100. >> > >> > A MySQL-specific autoincrement mapper could be implemented using >> > "SELECT last_insert_id()". I'm not familiar with Oracle, but it >> looks >> > like it also has sequences, and could be implemented using >> something >> > like "seq_name.CURVAL". >> >> On Jul 6, 2006, at 3:28 AM, David Adler wrote: >> >> > I would like to implement this and would like to check if anyone >> > has any >> > objections. The interface should not change except for >> > MaxIncFIDMapper >> > which I believe incorrectly returns hardcoded Types.VARCHAR for the >> > column >> > type when it should return the type of the actual fid column. >> > (Since it >> > assumes that the next fid value is MAX(key_column), it doesn't make >> > sense >> > for this to be a VARCHAR column). >> > >> > The complete work item is included below. It is difficult to test >> > whether >> > this breaks anything in RDBMS datastores which subclass fidmapper >> > classes >> > as I don't have databases other than DB2 and PostGIS installed. >> > >> > *** Issue details below *** >> > >> > The description of MaxIncFIDMapper states that it is only valid for >> > numeric >> > column types yet the method getColumnSize is hard-coded to return >> > Types.VARCHAR. It also is hard-coded to return a column size of >> 255. >> > >> > It should return the column type that was specified in the >> > constructor. >> > >> > AbstractFIDMapper has almost no function and all the subclasses >> have >> > considerable duplicated function. The duplicated function should be >> > factored up. >> > >> > There are also things that make no sense but I don't know if >> > anything will >> > break if they are changed. The getColumnXXX(int col) methods handle >> > index >> > out of bounds by returning null, 0 and ArrayIndexOutOfBounds. They >> > should >> > probably all return ArrayIndexOutOfBounds but this may break other >> > code >> > that doesn't handle an exception. >> > >> > >> > >> > Using Tomcat but need to do more? Need to support web services, >> > security? >> > Get stuff done quickly with pre-integrated technology to make your >> > job easier >> > Download IBM WebSphere Application Server v.1.0.1 based on Apache >> > Geronimo >> > http://sel.as-us.falkag.net/sel? >> > cmd=lnk&kid=120709&bid=263057&dat=121642 >> > _______________________________________________ >> > Geotools-devel mailing list >> > Geo...@li... >> > https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > >> >> >> >> --------------------------------------------------------------------- >> ---- >> Using Tomcat but need to do more? Need to support web services, >> security? >> Get stuff done quickly with pre-integrated technology to make your >> job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> http://sel.as-us.falkag.net/sel? >> cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Geotools-devel mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > |