1. Is probably a good strategy, and I think #3 is pretty similar.
I guess in my service layer, I would do something like this:
public class PersonService {
//...
void createPerson(String firstName, String lastName) {
try {
Person person = new Person(String firstName, String lastName);
PersonRecord record = this.ctx.newRecord(PERSON, person);
personDao.insert(person);
}
catch (SomeSQLException e) {
// Looks like the migration hasn't run yet and we are still on the
old
// version of the DB
com.myco.myapp.generated.compat.lastname.tables.pojos.Person person
= new com.myco.myapp.generated.compat.lastname.tables.pojos.Person(String
firstName);
com.myco.myapp.generated.compat.lastname.tables.records.PersonRecord record =
this.ctx.newRecord(com.myco.myapp.generated.compat.lastname.tables.Person.PERSON,
person);
personDaoCompat.insert(person);
}
}
}
Does that make sense?
--patrick
On Mar 24, 2016, at 10:23 AM, Lukas Eder
<[email protected]<mailto:[email protected]>> wrote:
@Samir, I think your suggestion might work, although the devil is in the
details...
@Patrick: Your requirements can be implemented in several ways:
1. You could abstract database versions in the DAO (or service) layer. You
would have two separate jOOQ generated jars, one for each version. The latest
version would reference "ordinary" package names, whereas the compatibility
overrides would reference the "previous" package names. 98% of all code can
always run against the "latest" version, because you probably don't change too
much between versions. Only a few DAOs would need to override the "latest" DAO
version to retain the "previous" behaviour. Once the migration is complete,
just delete the "previous" jars and the "previous" DAOs
2. You could abstract database versions in a view layer where you hide all
version specific behaviour in views, triggers, stored procedures, etc. This
way, you can modify the views to support the new latest database version, while
the Java code doesn't really have to change (and jOOQ wouldn't notice). This
might be a bit harder to implement thoroughly than #1
3. Instead of thinking in terms of "versions", you could think in terms of
"features", which are turned on/off. That way, each feature by itself would
need to check if some database column is available or not, etc. This approach
is probably only useful if you need to maintain dozens of versions in parallel.
I think that you should probably opt for solution #1, which is more or less
what Samir mentioned, too
2016-03-24 7:03 GMT+01:00 Samir Faci
<[email protected]<mailto:[email protected]>>:
Maybe I'm not understanding the problem properly but why couldn't you simply
use version control and standard java maven/ivy/gradle/ release cycle to do
this?
You have a snapshot of the schema (Jooq only inspects the schema anyways so
it's not like that data matters much).
When you commit a new change, it applies the SQL to a DB (real server, docker,
vagrant, pick your poison ) and generates a jar file with all the generated
classes with a pinned version.
For step 1 of getting a jar compatible with the older version is just a matter
of using an older release of the generated code.
Does that make sense or am I over simplifying your problem?
On Wed, Mar 23, 2016 at 9:23 AM, Patrick Armstrong
<[email protected]<mailto:[email protected]>>
wrote:
Thanks for the information Lukas.
Rollback would be an extreme situation I think, done by disconnecting the MySQL
secondary from the primary, then running the migration on the primary, then if
something goes wrong, restore from the secondary.
The more typical situation would be:
1. Deploy Java code that is compatible with the old version of the schema and
the new schema
2. Run the migration
3. Deploy Java code that removed the compatibility with the old version of the
schema.
The tricky part with JOOQ and code generation is step number 1 I think. I’m not
quite sure how I could use code generation in JOOQ with that type of situation.
On Mar 23, 2016, at 1:25 AM, Joseph Pachod
<[email protected]<mailto:[email protected]>> wrote:
Hi
No worries for the CC'ing.
For migrating up and down, you'll have to find a proper tool for it
(https://flywaydb.org/ doesn't support migrating down AFAIK).
On my side, just for migrating upwards, and needing all previous migrations
since we deploy on premises a
On Tue, Mar 22, 2016 at 1:31 PM, Lukas Eder
<[email protected]<mailto:[email protected]>> wrote:
Hi Patrick,
(Joseph, I hope you don't mind me CC'ing you for this discussion)
Thank you very much for your e-mail.
That is a very interesting idea, and we've actually had a very similar
discussion here on the user group, just recently:
https://groups.google.com/d/msg/jooq-user/I9iLbMQNN8o/Zrs-fi2bCQAJ
I'm curious myself how Joseph Pachod (who was starting that discussion) finally
managed to implement type safe versioning of their database with jOOQ.
In any case, I don't think it's a good idea to edit generated classes manually.
You don't know what kind of change we'll be implementing to support new
features in the next jOOQ minor release...
One approach that has served me well in the past was to avoid working with
tables directly, but work with views instead, in order to hide (some) database
migration details from the client.
If you have any specific ideas / concerns, I'm very happy to discuss (and
hopefully, others might chime in, too)
Best,
Lukas
2016-03-21 23:22 GMT+01:00 Patrick Armstrong
<[email protected]<mailto:[email protected]>>:
Hi there,
I'm looking at using JOOQ for a project, and am curious about the idea of using
the code generation once per new table, then keeping these objects updated
manually afterwards as the database schema evolves. We are planning on doing
migrations without downtime, so we'd like the flexibility to be able to
rollback if there's a problem with an update, so code needs to be able to work
with a pre-migration and post-migration database.
What do you think about that idea? Would it be better to just forgo the code
generation features in my use case?
--patrick
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
[email protected]<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
[email protected]<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
[email protected]<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
Thank you
Samir Faci
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
