Skip to content

Reduce need for script duplication when adding support for a new database type [DATAJDBC-537] #757

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Tracked by #756
spring-projects-issues opened this issue May 6, 2020 · 0 comments
Assignees
Labels
in: schema-generation status: ideal-for-contribution An issue that a contributor can help us with type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link

Mark Paluch opened DATAJDBC-537 and commented

Currently, we're required to duplicate and adapt several scripts (a schema file per integrationtest) if we decide to add support for a new database. We should revisit this arrangement to investigate on alternatives. Ideally, we can describe schema objects in a vendor-neutral way and then generate scripts by considering vendor-specifics.

One idea could be the use of Liquibase change files or the direct use of the Liquibase API to generate schema objects. We should consider this change in the light of DATAJDBC-536


Issue Links:

@spring-projects-issues spring-projects-issues added the type: enhancement A general enhancement label Dec 31, 2020
@kurtn718 kurtn718 self-assigned this Mar 30, 2023
@schauder schauder added the status: ideal-for-contribution An issue that a contributor can help us with label Sep 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: schema-generation status: ideal-for-contribution An issue that a contributor can help us with type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants