GeoTools

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

is related to

New Feature - A new feature of the product, which has yet to be developed. GEOT-379 PostgisFIDMapperFactory should be configurable

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: