GeoTools
  1. GeoTools
  2. GEOT-721

FIDMappers should be configurable

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.M0
    • Fix Version/s: 2.3.6
    • Component/s: main
    • Labels:
      None

      Description

      In DataStores derived from JDBCDataStore, and probably in all others as well,
      there is a default of false for returnFIDColumnsAsAttributes() for all FIDMappers.
      This should instead be configurable, so that one can decide upon it.
      I know that with an explicit cast to JDBCDataStore you can call setFIDMapper()
      and change this behaviour, but this is cumborsome and also it's not applicable
      to all DataStores.
      But the real bad thing is that it's not usable from GeoServer, since it's not usable
      from the DataStoreFactory.
      In my opinion ALL parameters should be accessible through the DataStoreFactory,
      there should never be any case where one must configure a DataStore with using
      its DataStoreFactory.

        Issue Links

          Activity

          Hide
          Jody Garnett added a comment -
          FIDMappers should not exist - a DataStore should know what is going on for its data. If there is configuration to be had it should take responsibility for storing this information (or derriving it from the existing metadata).

          This is a fundemental flaw in DataStore factory, the difference between indentity (which data) and configuration (how you want it served up) is not explicit. Have a look at GeoResouce interfaces for a smarter replacement for DataStoreFactory.

          Even so this is not a complete answer to the issue of configuration, I basically agree with your last sentence (which is probably a typo). I think one should specifiy with a DataStoreFactory and configure the DataStore directly.

          Note - this is a topic for the email lists....
          Show
          Jody Garnett added a comment - FIDMappers should not exist - a DataStore should know what is going on for its data. If there is configuration to be had it should take responsibility for storing this information (or derriving it from the existing metadata). This is a fundemental flaw in DataStore factory, the difference between indentity (which data) and configuration (how you want it served up) is not explicit. Have a look at GeoResouce interfaces for a smarter replacement for DataStoreFactory. Even so this is not a complete answer to the issue of configuration, I basically agree with your last sentence (which is probably a typo). I think one should specifiy with a DataStoreFactory and configure the DataStore directly. Note - this is a topic for the email lists....
          Hide
          Paolo Rizzi added a comment -
          Yes, sorry, it was a typo, the correct phrase was:
             "..there should never be any case where one must configure a DataStore WITHOUT using
             its DataStoreFactory...".

          Instead this is interesting:
             "...This is a fundemental flaw in DataStore factory, the difference between indentity
             (which data) and configuration (how you want it served up) is not explicit...".

          So you're saying that there should be exactly just ONE instance of a DataStore (hence just
          ONE DB connection) for each DB and then there may exists several HowWeWouldCallThem
          that let's you see that single DataStore in different ways???

          That sounds like mapping, something Gabriel is/will working on, or not???

          I put this in the list, so it won't go unnoticed.
          Show
          Paolo Rizzi added a comment - Yes, sorry, it was a typo, the correct phrase was:    "..there should never be any case where one must configure a DataStore WITHOUT using    its DataStoreFactory...". Instead this is interesting:    "...This is a fundemental flaw in DataStore factory, the difference between indentity    (which data) and configuration (how you want it served up) is not explicit...". So you're saying that there should be exactly just ONE instance of a DataStore (hence just ONE DB connection) for each DB and then there may exists several HowWeWouldCallThem that let's you see that single DataStore in different ways??? That sounds like mapping, something Gabriel is/will working on, or not??? I put this in the list, so it won't go unnoticed.

            People

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

              Dates

              • Created:
                Updated: