If you have any postgis/database experience I would really appreciate some patches. I'm going to work on the editing/commits etc... but I'm far from an experienced database hacker. Even providing me with some SQL statements that I could use would be of great help to me.
Jesse On 6-Jun-06, at 5:06 PM, Michael Brasser wrote: > Jesse, > > Thanks for the clarifications, that helps. A few additional thoughts: > > 1. I think Chris' suggestion is a good one -- oid's were phased out > as of 8.1, so it would probably be good to check the version number > before using them. Likewise, PostGISAutoIncrementMapper can't be used > for versions prior to 8.0 (right?). > > 2. 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". > > Regards, > Michael > > On May 30, 2006, at 12:42 AM, Chris Holmes wrote: > >> Hey, if anyone's hacking on this code, could you put in a bit of a >> better error report? >> >> Now that many people are using postgres 8, when they forget their >> primary key they get a message about oid's not found. Perhaps have >> that error report say 'no oid's found - if you are using postgres 8 >> or later you need to define a primary key on your data'. >> >> The more elegant way would be to check the version before trying to >> use the oidfidmapper, and if there's no primary key and it's later >> than when oid's were phased out raise the right message about no >> primary key. But the former's probably easier, and would work fine. >> >> Chris >> >> Jesse Eichar wrote: >>> Hi Michael, >>> I was preparing for a demo so it is possible that the classes are >>> redundant and I didn't have time to correctly investigate the >>> issue. I'm looking into it now and this is my current >>> understanding, anyone can correct me I'm still learning postgis. >>> OIDFidMapper and PostGISAutoIncrementMapper are not redundant >>> because: >>> 1. OIDFidMapper is used when there is no Primary key and as a >>> last resort. PostGISAutoIncrementMapper is used when there is a >>> primary key. >>> 2. The implementation of createID in PostGISAutoIncrementMapper >>> only works on postgres 8+ databases. If the db is not a postgres >>> 8+ then it uses the AutoIncrementFIDMapper to obtain the featureID. >>> MaxIncFIDMapper and AutoIncrementFIDMapper are not redundant >>> because MaxIncFIDMapper is used when the primary key is NOT >>> autoincrement. The implementations are the same because I don't >>> know a way in SQL to query for the last returned item in the >>> sequence and so ended up using the same query. If there is no >>> way to make that query then perhaps AutoIncrementFIDMapper should >>> be abstract and all datastore should have their own subclass of >>> AutoIncrementFIDMapper. >>> Comments are welcome. >>> Jesse > > > > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
