Closed spring-projects-issues closed 4 years ago
Wayne Lund commented
I'm realizing that this has never been addressed and SQLFire's next release is GemfireXD standalone edition. This issue will add gfxd- as well as fix the sqlf- issues from auto generation for both, which are very closely related. Can we move this issue to spring-batch-3.0 or should I create a new issue?
Wayne Lund commented
We have an issue with including Fire samples, which currently adding the required files to support datasources, schema generation (vpp), database type, etc to run the samples on the Fire databases. We can't mix the jars. To upgrade to run gemxd I ended up having to comment out spring-data-gemfire and sqlfire-client to avoid a library conflict documented here - https://support.pivotal.io/hc/communities/public/questions/201356113-Resultset-not-working-in-gemfire-xd-NoSuchMethodError-com-gemstone-gnu-trove-TObjectIntHashMap-putIfAbsent-Exception#answer-202697763. It was pulling a conflicting method from gemfire jar instead of gemxd-client.
Options:
1) How widely used is spring-batch-samples? Is it better to use the idea of gs-batch-processing and have separate blogs for demonstrating different flavors of db types, partitioning types, etc. etc? 2) Postpone adding gemfirexd until gemfire and gemfirexd are a single project to avoid this type of conflict.
Closing this issue since the auto-generation of sql scripts has been removed (see f19f32fd79a340b798ab84f21216b4668f79e15a). Moreover, the issue is related to sqlfire support which has been deprecated in #815 .
Wayne Lund opened BATCH-1963 and commented
After creating sqlfire*.sql files for core and samples and modifying postgresql I realized that these are meant to be auto-generated. I've added the creates and mods into the src/main/sql/\ and am creating the distinct way postgres has to drop constraints when cleaning out the database.
Affects: 3.0.2