GeoTools
  1. GeoTools
  2. GEOT-379

PostgisFIDMapperFactory should be configurable

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: jdbc-postgis plugin
    • Labels:
      None

      Description

      At least you should be able to decide if you want PKs fields returned or not. The problem is that all the FIDMappers that PostgisFIDMapperFactory returns have a returnFIDColumnsAsAttributes() that always return false. This is OK with the OIDFidMapper, since you probably have no interest on OIDs, but with other FIDMapper types, chances are that you really need PKs fields.
      I have a fixed version of PostgisDataStore (albeit it's not general enough to be used as is) that fixed almost all of the above. Where and how can I submit it???

      Bye
      Paolo Rizzi

        Issue Links

          Activity

          Hide
          Chris Holmes added a comment -
          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.
          Show
          Chris Holmes added a comment - 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.
          Hide
          Paolo Rizzi added a comment -
          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... :)
          Show
          Paolo Rizzi added a comment - 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... :)
          Hide
          Chris Holmes added a comment -
          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.
          Show
          Chris Holmes added a comment - 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.
          Hide
          Paolo Rizzi added a comment -
          This is essentially the same as
             http://jira.codehaus.org/browse/GEOT-721

          so it should be resolved for all DataStores.
          Show
          Paolo Rizzi added a comment - This is essentially the same as     http://jira.codehaus.org/browse/GEOT-721 so it should be resolved for all DataStores.
          Hide
          Andrea Aime added a comment -
          Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update
          Show
          Andrea Aime added a comment - Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update

            People

            • Assignee:
              Chris Holmes
              Reporter:
              Paolo Rizzi
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: