[
https://issues.apache.org/jira/browse/GEODE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17275294#comment-17275294
]
ASF GitHub Bot commented on GEODE-8626:
---------------------------------------
agingade commented on pull request #5637:
URL: https://github.com/apache/geode/pull/5637#issuecomment-770014534
> @agingade This PR is ready to be reviewed. Please review it when you're
available.
@masaki-yamakawa
Participants in team discussion: @jchen21 @dschneider-pivotal
Thanks for your PR. Sorry for delay in responding to this.
We had a team discussion around this PR as it deflects from the way Geode
configuration is done (the recommended way). In the past Geode/GemFire was
built with cache.xml as a way to configure the system; based on its drawback
and keep the overall cluster configuration easier, it was decided to
adopt/build Cluster Configuration Service with gfsh as the tool to accomplish
it (currently there is work getting done to support the same through new
management APIs). As the Cluster Configuration Service got matured, the use of
xml is gradually getting deprecated.
The change proposed with this ticket/PR feels like going back to the
cache.xml way of configuring the system. Can you please let us know the reason
behind not using the cluster configuration service and going with cache.xml; we
would like to understand more about the usecase/requirement and see if there
are any other better options.
Also, you can achieve what you are looking for, by exporting the cluster
configuration info (once defined using gfsh - which is an xml output) and then
importing it to any test/dev/prod system. Can this suffice your requirement?
On the other note, based on the PR review, it expects the user class to be
in the server side classpath; currently this is not a requirement while using
PDX type/object; one of the main functionality of PDX is to support data stores
without needing a class definition on the server. The product takes care of
this internally when one configures the jdbc mapping automatically.
Please let us know your thoughts.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Omitting field-mapping tag of cache.xml when using Simple JDBC Connector
> ------------------------------------------------------------------------
>
> Key: GEODE-8626
> URL: https://issues.apache.org/jira/browse/GEODE-8626
> Project: Geode
> Issue Type: Improvement
> Components: jdbc
> Reporter: Masaki Yamakawa
> Priority: Minor
> Labels: pull-request-available
>
> When configuring Simple JDBC Connector with gfsh, I don't need to create
> field-mapping, the default field-mapping will be created from pdx and table
> meta data.
> On the other hand, when using cache.xml(cluster.xml), pdx and table meta data
> cannot be used, and field-mapping must be described in cache.xml.
> I would like to create field-mapping defaults based on pdx and table meta
> data when using cache.xml.
> If field-mapping is specified in cache.xml, the xml setting has priority, and
> only if there are no field-mapping tags.
> cache.xml will be as follows:
> {code:java}
> <region name="Region1" refid="REPLICATE">
> <jdbc:mapping
> data-source="TestDataSource"
> table="employees"
> pdx-name="org.apache.geode.connectors.jdbc.Employee"
> ids="id">
> <!-- no need to jdbc:field-mapping tag
> <jdbc:field-mapping pdx-name="id" pdx-type="STRING" jdbc-name="id"
> jdbc-type="VARCHAR" jdbc-nullable="false"/>
> <jdbc:field-mapping pdx-name="name" pdx-type="STRING"
> jdbc-name="name" jdbc-type="VARCHAR" jdbc-nullable="true"/>
> <jdbc:field-mapping pdx-name="age" pdx-type="INT" jdbc-name="age"
> jdbc-type="INTEGER" jdbc-nullable="true"/>
> -->
> </jdbc:mapping>
> </region>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
