PostgisFIDMapperFactory should be configurable

James Macgill added a comment - 20/Jan/05 9:54 AM Please attach your files to this JIRA issue. I will link together all of the issues which relate to it.

Paolo Rizzi added a comment - 21/Jan/05 1:04 PM This is my version of the PostgisDataStore. Please use it as-is. Comments are not at their best... And there's commented out code that can be removed. Also the createSchema() will print out all the SQL it creates, even if the table already exists. This can be useful to recreate it later, but it should be configurable. New files are named SISxxx and there are comments in the code marked as "SISfixed". Feel free to ask me for any explanation.

Chris Holmes added a comment - 16/Feb/05 9:14 PM Hey, this patch is pretty hard to dig through, since it does not easily diff against the current working stuff - I am going to have to dig through by hand and figure out all the changes. I know you point them out, but if you were to just modify the PostgisDataStore file directly then I could just diff. And/or from that you (or I) could easily generate a patch that can be applied super easily. The extension of the datastore is nice if you're working with closed code where you can't modify the source - but with open source its easiest to fix bugs by just changing the source as you need it. I will do my best to dig through these (unless you somehow could easily send just a modified postgisdatastore), but in the future please don't extend and over-ride, just modify directly and submit that. thanks! Chris

Chris Holmes added a comment - 17/Feb/05 12:18 AM linked to 379, which has all the submitted code.

Paolo Rizzi added a comment - 17/Feb/05 5:39 AM I'm sorry for that!!! While I do produce software since many many years, it's my first time with Open Source, so I didn't even think to directly modify postgisdatastore. Also I always worked alone in the past, so I'm also new to CVS/SVN, I still don't know what diff and patch actually are... Next time I'll do a better job, but at the moment I really can't easily rework the postgisdatastore, also because we're stil using GeoTools 2.0 (until GeoServer switch to 2.1). Bye Paolo

Chris Holmes added a comment - 17/Feb/05 4:31 PM linked to 379, as it contains the fixes.

Chris Holmes added a comment - 17/Feb/05 4:53 PM No worries at all. Sorry if my email came off as fairly annoyed - I was just expecting less work. But there is some great work there. I just committed some of the fixes, but most will need to hold off. I need to grapple with a few design issues first. I did fix all the double quotings. And I put in the spatial index creation - I think that's a great improvement. I started to put in the AddGeometryColumn stuff, but then I remembered why we did things as we did in the first place. It is there to maintain the order of geometry attributes. Order does matter in GeoTools, and the code _should_ work so that if you have a geometry attribute in a position other than last it shows up there - so that the FeatureType you added stays the same. This should maybe change, since it is a bit of a ridiculous requirement, and shapefiles for example could never meet it. I think the thing to do will be to dissociate featureTypes from the physical data representation - using mappings and whatnot. We definitely want to go in that direction, see the GeoServer 1.3 roadmap. Would love your feedback when I throw up my thoughts, as it looks like you're going in that direction too. It will leave a bit of a challenge how to do createSchema - but it will at least be possible - if there is room for a looser mapping. Check my comments in the source code - http://svn.geotools.org/geotools/trunk/gt/plugin/postgis/src/org/geotools/data/postgis/PostgisDataStore.java And welcome to open source programming. Don't hesitate to ask questions, it's needed to get us all working together. Try out svn diff on a file, like after you have modified it a bit - it will report all the changes that you have made to it. It's super useful. If you don't like the changes you can type 'svn revert', and it will take all your changes back. There is lots of functionality - check out the svn book at: http://svnbook.red-bean.com/index.en.html Also GeoServer will be on 2.1 relatively soon. The trunk of GeoServer is against 2.1. So if your working on GeoServer svn you _should_ be using GeoTools trunk (2.1). But no worries if you're not there yet, it's still a bit unstable - we should get it more so in the next few weeks.

Paolo Rizzi added a comment - 21/Feb/05 6:34 AM I didn't know there was a requirement about attribute order, and it didn't matter that much for us, that's why I used AddGeometryColumn(), even if it puts geom columns at table end. Using direct insert into the geometry_columns attains the very same result, so it is no problem at all, but I'm pretty sure you must set the correct specific geometry type into the "geometry_columns.type" column ("POINT", "MULTILINESTRING", etc.) and not the generic "GEOMETRY" type, otherwise you got errors in some client code (I don't exactly remember, but I think GeoServer won't publish the correct column type in its automatically generated feature schema if the column type isn't set to the specific type). Yes, we have a Meta information infrastructure that let us describe types independently from their physical implementation and from FeatureType as well. This way we can define our data model in an implementation independent way and then automatically build FeatureTypes on the fly, without even needing to have a DataStore to store them. The Meta information for each type contain all the information present in FeatureType and AttributeType, plus other, for example the fact that an Attribute is a Primary Key. This is what is missing to finish the implementation of createSchema(). As soon as our Meta information infrastructure is stable enough, I'll send it to you, hoping it can be useful. Thank you for your suggestions about diff, I'll try it and in the future I'll be more compliant with the best practices, it's a matter of experience. Yes, we're developing quite a lot on our side, so we need to use something as stable as possible, otherwise we'll risk to mess it all up. So we'll stuck with GeoTools 2.0 and GeoServer 1.2.4 until the 2.1 and the corresponding GeoServer are not released as FINAL. Bye Paolo Rizzi P.S: It's really not important but, since I'm Italian, my true name is Paolo, not Paulo... :)

Chris Holmes added a comment - 21/Feb/05 7:28 PM Ok, I just updated the pgdatastore on 2.1 to (hopefully) get the geometry name right in the geometry column. And I corrected your name, sorry about that. I am very, very interested in your Meta work, as that's basically the problem I want to tackle next in geotools and geoserver. We want to have featureTypes completely decoupled from their physical datastores, and allow users to do joins, and new mappings - in order to match existing schemas with their current databases. I've been struggling for awhile with the design implications, trying to get it right in my head and not coming out with much. So seeing how you tackled it would be very nice. If you could, add a nice overview to the wiki - http://docs.codehaus.org/display/GEOTOOLS/RnD Even if you haven't completed the full implementation yet I would be interested to see the problems you're attempting to tackle and the approach you've taken. I hope to try to design something in the next week or two, and would be nice to have your use case included.

Paolo Rizzi added a comment - 11/Oct/05 5:29 AM This is essentially the same as     http://jira.codehaus.org/browse/GEOT-721 so it should be resolved for all DataStores.

Andrea Aime added a comment - 28/Nov/10 2:56 AM Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update