GeoTools
  1. GeoTools
  2. GEOT-2511

JDBCJNDIDataStoreFactory misses the schema parameter

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.5.5
    • Fix Version/s: 2.5.6, 2.6-M2
    • Component/s: jdbc
    • Labels:
      None

      Description

      The schema params is not part of the advertised params in JDBCJNDIDataStoreFactory, meaning the datastores will fall back into whatever the default schema is

        Issue Links

          Activity

          Hide
          Andrea Aime added a comment -
          The fix should be to just add
          parameters.put(SCHEMA.key, SCHEMA);
          inside
          protected void setupParameters(Map parameters)

          Was there any reason why the schema was not included among the params thought?
          Show
          Andrea Aime added a comment - The fix should be to just add parameters.put(SCHEMA.key, SCHEMA); inside protected void setupParameters(Map parameters) Was there any reason why the schema was not included among the params thought?
          Hide
          Justin Deoliveira added a comment -
          Probably just missed. Christian, any objecetions?
          Show
          Justin Deoliveira added a comment - Probably just missed. Christian, any objecetions?
          Hide
          Christian Mueller added a comment -
          The used db schema is specified with the datasource (like user, password, connection pool settings, .....) . At least for DB2 I am absolutely sure about that fact. No need for specifying a db schema name in the JDBCJNDIDataStoreFactory.

          If no schema name is given, the user id is the current schema. Look at the the vendor specific DataSource properties how to specify a different schema name.

          I think, we have no bug here or I have to learn something :-)



          Show
          Christian Mueller added a comment - The used db schema is specified with the datasource (like user, password, connection pool settings, .....) . At least for DB2 I am absolutely sure about that fact. No need for specifying a db schema name in the JDBCJNDIDataStoreFactory. If no schema name is given, the user id is the current schema. Look at the the vendor specific DataSource properties how to specify a different schema name. I think, we have no bug here or I have to learn something :-)
          Hide
          Andrea Aime added a comment -
          The JDBCDataStore uses the schema parameter to build up queries. I would not be surprised if setting up a container shared pool the admin would still want to have each application hit a different database schema.
          In fact, DBCP does not have a schema property in its configuration (http://commons.apache.org/dbcp/configuration.html) and the PostGIS driver does not allow for a schema specification either:
          http://jdbc.postgresql.org/documentation/83/connect.html#connection-parameters

          It seems to me for DB2 (and Oracle) we're seeing a side effect that a user has a its own default schema (usually with the same name as the user) but this is not the rule in other databases.
          Show
          Andrea Aime added a comment - The JDBCDataStore uses the schema parameter to build up queries. I would not be surprised if setting up a container shared pool the admin would still want to have each application hit a different database schema. In fact, DBCP does not have a schema property in its configuration ( http://commons.apache.org/dbcp/configuration.html ) and the PostGIS driver does not allow for a schema specification either: http://jdbc.postgresql.org/documentation/83/connect.html#connection-parameters It seems to me for DB2 (and Oracle) we're seeing a side effect that a user has a its own default schema (usually with the same name as the user) but this is not the rule in other databases.
          Hide
          Justin Deoliveira added a comment -
          That makes sense... sometimes the schema is "built-in" (for lack of a better term) to the connection, and sometimes not. So... I think the best way forward would be to add the schema parameter (optional) and db2 and oracle can ignore it.
          Show
          Justin Deoliveira added a comment - That makes sense... sometimes the schema is "built-in" (for lack of a better term) to the connection, and sometimes not. So... I think the best way forward would be to add the schema parameter (optional) and db2 and oracle can ignore it.
          Hide
          Christian Mueller added a comment -
          In postgres a user has also his default schema

          http://sql-info.de/en/postgresql/schemas.html#Practical%20schema%20usage

          Anyways, specifying the schema name along with the datasource is not supported by all databases, we should add the schema parameter(optional)

          Who ?

          Show
          Christian Mueller added a comment - In postgres a user has also his default schema http://sql-info.de/en/postgresql/schemas.html#Practical%20schema%20usage Anyways, specifying the schema name along with the datasource is not supported by all databases, we should add the schema parameter(optional) Who ?
          Hide
          Andrea Aime added a comment -
          Do we want it to be general, and thus show up in DB2 as well, or not?
          I guess the simplest way to go, since apparently schema support in the connection is not common, would be to have the schema optional as you say, and eventually have db2 jndi factory override the setupParameters method to skip it?
          Show
          Andrea Aime added a comment - Do we want it to be general, and thus show up in DB2 as well, or not? I guess the simplest way to go, since apparently schema support in the connection is not common, would be to have the schema optional as you say, and eventually have db2 jndi factory override the setupParameters method to skip it?
          Hide
          Christian Mueller added a comment -
          Make it general and slimple , DB2 should offer both possibilities.
          Show
          Christian Mueller added a comment - Make it general and slimple , DB2 should offer both possibilities.
          Hide
          Christian Mueller added a comment -
          Fixed on 2.5.x and on 2.6.x, added SCHEMA parameter
          Show
          Christian Mueller added a comment - Fixed on 2.5.x and on 2.6.x, added SCHEMA parameter

            People

            • Assignee:
              Christian Mueller
              Reporter:
              Andrea Aime
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: