Thanks a lot for your feedback, Bernd, greatly appreciated! On Mon, May 20, 2024 at 1:08 PM 'Bernd Huber' via jOOQ User Group < jooq-user@googlegroups.com> wrote:
> I even searched for a jOOQ sticker online to put on my work laptop, but > thats something still missing :) > You get stickers if you talk at conferences / user groups! :) > 1. Contexts > > Liquibase allows changesets to be associated with context(s). > I need to be able to associate my changesets in two differents contexts: > "ddl", "dml". > Because then i can provide following workflow: > - Execute all "ddl" changesets, but only mark "dml" changesets as executed > (do not execute them). > > This way i can always create an empty schema that does not contain data. > Please see my blog-post (its still a draft) about this topic: > - https://funkrusher.de/2024/05/20/database-operations/ > I can see how this adds some value for development, but in my experience, it's a lot more messy than that. A "changeset" (i.e. something that should ideally deploy atomically) often involves creating objects (even temporary one), preparing data, creating more objects, creating objects dynamically based on data, deleting temporary data again, dropping temporary objects. Perhaps, this isn't what everyone was doing, but we certainly did this a lot of times where I worked before. Anyway, perhaps for more simple cases, it's already good enough to have this simple view of things being strictly DDL or DML. > 2. Developers can work on different changesets at the same time (with Help > of Tags, Rollbacks and free filenames) > > Because in liquibase changeset-files can get free filenames > ("featurexyz.xml") there are less conflicts. > - Peter can work on "featurexyz.xml" in his Git-Branch "featurexyz" > - Maria can work on "featureabc.xml" in her Git-Branch "featureabc" > > Maria is going to Vacation for 1 Week. Now Peter can manually Rollback his > "featurexyz.xml" because he gave the changeset contained in this XML-File > a specific Tag ("featurexyz"). He executes Liquibase Rollback manually > (via a gradle task for example) and rollbacks this changeset locally > (Rollback-Sqls are executed) > Now he checkout Marias Git-Branch, and starts his App. Now Marias > Changeset "featureabc" is executed. > > In other Migration-Tools like Flyway or Play-Evolutions the Filenames > often need to have ascending order, like: "001.sql", "002.sql". > For the described use-case, Maria and Peter would have both worked on the > File "002.sql", and this File would need to contain Rollback-Sql also. > When Maria merges her Branch into the Dev, and Peter merges the Dev into > his Branch he will need to resolve a Git-Conflict first. He would need to > rename his 002.sql > to 003.sql and override his 002.sql with Marias 002.sql. > Yes, I never liked Flyway's strict ordering of files based on manually assigned numbers. That makes merging branches very painful. I have something even better in mind, but am not confident enough to talk about it in detail yet. Just think about it this way, you've already completely versioned all branches and merges in git, so in theory, everything could be derived automatically from this history (along with jOOQ's diff and DDL interpretation capabilities, etc.). > What i dislike about Liquibase. > > Liquibase has no option to execute all Changesets in one! Transaction. > Each Changeset is executed in a Transaction. > When one of the Changesets fail for any reason (maybe even during > Live-Deploy) the Developer / Dev-Ops Person must fix this State where some > changesets > have already been applied successfully, while the rest could not be > applied because of an error. > If all changesets could be forced to be executed in One! Transaction (some > Databases support this), it would be much safer. > That's the ideal, of course. Though it's already good that a unit can be executed atomically. > The XML-Files are maintenance intensive because they are very "speaky". I > need to provide multiple Identifiers for the changeset: > - Author > - Id > - Tag > - Context > - Ids need to be references sometimes again in the chageset.. > > Intellij does not show the <sql> in an XML-Changeset nicely, but mostly i > would want to use plain SQL and not the Liquibase XML-Syntax (even though > it is typesafe), > because it should be possible to always get the plain SQL of those > changesets, because sometimes a release-deployer or dev-ops person should > be able (in case of error) > to manually apply them safely to the database. Im not really sure if > liquibase can also generate SQL out of the XML-Format, and if i should use > this. > I would believe that Liquibase can export the generated SQL through logs, dry runs, no? It's certainly something jOOQ will be capable to do, through various APIs, irrespective of the storage format for the migration scripts (both SQL and XML will certainly be supported, I doubt that I'll support YAML or JSON, they're both worse formats than XML for structured data, in my opinion) > Play-Framework: > > The Play-Evolutions during startup automatically detect, if the local > Migration-Files are before/behind the applied migrations, > and if there is a discrepancy (diff). > > When Play-Evolutions detects that there is a Diff at some evolution: > - It rollbacks all evolutions in backward ordering until it reaches this > diff evolution and also rollbacks this. > - Afterwards it forward-migrates this evolution again and also all > evolutions coming after this one. > > This perfectly supports the typical Workflow of Developers, when they need > to: > - switch branches > - work on different feature-branches that contain different new migrations > (be able to fastly rollback and apply evolutions in different development > branches) > > Play-Evolutions has a very nice Local Developer Workflow going on, which > mainly consists of a Small UI in the Webbrowser, that has an "Apply > Evolutions" Button. > When there are errors, one could easily see the problematic code part in > the browser and could manually fix his Db and afterwards click on the > "Apply Evolutions" Button again, > to continue with his business without much interference. > I see, this is also prototyped in jOOQ-migrations as well, already. Branch switching should always be possible very easily in dev, maybe even simpler than what you describe here. Though I haven't done the exercise of looking into all the tons of edge cases yet, so it might be that jOOQ-migrations will work almost like what you described here after all. > It would be cool if jooq-migrations: > > - would also be able to automatically! rollback changesets until the Diff > (like play evolutions). Liquibase can not rollback automatically, only > manually. > - has contexts like liquibase to put changesets into different categories. > - has unique changeset ids like liquibase that do not produce git > conflicts (not like play-evolutions). > Yeah, all those boxes will be checked. -- 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 jooq-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO4LP5S87rBA9xyHJ%2BNxdiEHMA7Jrm6YH9EnFrPoGpBPBQ%40mail.gmail.com.
