I use my liqibase scripts for Jooq code generation. As I learned from the instructions and log, the Dialect is H2.
Is that a problem if the application runs against a SQL Server database afterwards? Does the code generation have to be adjusted or do the metaclasses remain the same?
<plugins>
<plugin>
<groupId>org.jooq</groupId>
<artifactId>jooq-codegen-maven</artifactId>
...
<configuration>
<generator>
<name>org.jooq.codegen.JavaGenerator</name>
<database>
<name>org.jooq.meta.extensions.liquibase.LiquibaseDatabase</name>
The LiquibaseDatabase can be used for simple database schemas where it is desirable not to connect to an actual database instance (e.g. for performance reasons) in order to generate code. It's drawbacks are that it's not an actual SQL Server database, but a simulated migration - currently on an in-memory H2 database. This means that some vendor specific functionality may not work as expected.
It is usually better not to use the above utility for more complex schemas with vendor specific features (e.g. stored procedures, etc.). Instead, use the SQLServerDatabase that connects to an actual database instance.
You could still use Liquibase on a testcontainers based SQL Server instance to set up your schema prior to generating jOOQ code, as explained in this blog post here.
Related
What does your approach to generating Records during compilation time look like without connection to the database? I use to maven plugin for that but I still need a connection to the database but I don't have one.
jOOQ offers 4 out of the box solutions to generating code without a connection to a live database, including:
JPADatabase if your meta data source of truth is encoded in JPA annotations
XMLDatabase for XML based meta data
DDLDatabase for DDL script based meta data (e.g. Flyway migrations)
LiquibaseDatabase for liquibase migration based meta data
All of the above meta data sources come with their own set of limitations, including lack of support for some vendor specific stuff, but that might not affect you. In simple cases, especially the DDLDatabase can be really useful to achieve quicker turnarounds when generating code.
If vendor specific functionality is a thing in your application, then the official recommendation is to use testcontainers to set up your schema for jOOQ code generation (and integration testing!).
suppose I have following usecase:
I want my application to run against PostgreSQL
I have configured jooq-codegen-maven plugin to use H2
It is bacause I dont want to my builds be dependent against always running postgres
Questions:
Is generated code against H2 compatible with usage with postgres?
Does this usecase makes sense?
If not, how to solve it correctly (beeing less dependent to running DB instance)?
Can I use (somehow) testcontainers with generation process (or some similar concept)
Thank you
Ivos
Is generated code against H2 compatible with usage with postgres?
Yes, as long as you don't use any vendor specific features
Does this usecase makes sense?
Sure, but I'd try other things first, including running a PostgreSQL instance in testcontainers. jOOQ might support that out of the box in the future: https://github.com/jOOQ/jOOQ/issues/6551. In the meantime, here's an example showing how to set it up manually, it's not too hard: https://github.com/jOOQ/jOOQ/tree/main/jOOQ-examples/jOOQ-testcontainers-example
Also, rather than rolling your own PostgreSQL/H2 setup, you could just use the DDLDatabase, which translates PostgreSQL DDL to H2 as of jOOQ 3.13, and in the future, will simply interpret the DDL, to support more vendor specific stuff.
I'm currently building a rest api and I'm struggling to find the best way to unit test each route.
A route handler performs various things and one of them is to execute a query to mongodb. I can unit test the route handler by using stubs, but if I'm testing the query I cannot stub the query itself, I need to have an in-memory mongodb that I could reset and insert new data for each test.
How do you test queries? I'm thinking that the only real way to ensure that the query does what I need is to use a real mongodb database installed in the testing machine (typically in the same machine used for developing).
yes, just as for relation databases, you need to have real base. if mongo offers in-memory auto-created version then it's easy. if not, then each developer has to have running mongo before he runs integration tests. for CI you can have one single dedicated mongo but than you have to prevent concurrent access (schema creation, multiple transactions etc). you should also implement automatic creation of schema if needed and empty database before each test. in relational db rollback is usually enough. when it's not enough then trimming all tables helps. although we had to implement it manually as we couldn't find any existing tools
I'm working on a node.js server, and using MongoDB with node-mongo-native.
I'm looking for a db migration framework, similar to Rails migrations. Any recommendations?
I'm not aware of a specific native Node.js tool for doing MongoDB migrations .. but you do have the option of using tools written in other languages (for example, Mongoid Rails Migrations).
It's worth noting that the approach to Schema design and data modelling in MongoDB is different from relational databases. In particular, there is no requirement for a collection to have a consistent or predeclared schema so many of the traditional migration actions such as adding and removing columns are not required.
However .. migrations which involve data transformations can still be useful.
If your application is expecting data to be in a certain format (eg. you want to split a "name" field into "first name" and "last name") there are several strategies you could use if the idea of using migration tools written in another programming language isn't appealing:
handle data differences in your application logic, so old and new data formats are both acceptable (perhaps "upgrading" records to match a newer format as they are updated)
write a script to do a once off data migration
contribute MongoDB helpers to node-migrate
I've just finished writing a basic migration framework based on node-mongo-native: https://github.com/afloyd/mongo-migrate. It will allow you to migrate up & down, as well as migrating up/down to a specific revision number. It was initially based on node-migrate, but obviously needed to be changed a bit to make it work.
The revision history is stored in mongodb and not on the file system like node-migrate, allowing collaboration on the same project using a single database. Otherwise each developer running migrations could cause migrations to run more than once against a database.
The migrations themselves are file-based, also helping with collaboration on a single project where each developer is (or is not) not using the same database. So when each dev runs the migration, all migration files not already run against his/her database will be run.
Check out the documentation for more info.
I currently developed an app that connects to SQL Server 2005 database, so my DAL objects where generated using information from that DB.
It will also be possible to connect to an Oracle and MySQL db, all with the same table structures (aside from the normal differences in fields, such as varbinary(max) in SQL Server and BLOB in Oracle, and so on). For this purpose, I already defined multiple connection strings and multiple SubSonic providers for the different DB's the app will run on.
My question is, if I generated my objects using a SQL Server database, should the generated objects work transparently with the other DB's or do I need to generate a different DAL for each database engine I use? Should I be aware of any possible bugs I may encounter while performing these operations?
Thanks in advance for any advice on this issue.
I'm using SubSonic 2.2 by the way....
From what I've been able to test so far, I can't see an easy way to achieve what I'm trying to do.
The ideal situation for me would have been to generate SubSonic objects using SQL Server for example, and just be able to switch dynamically to MySQL by just creating at runtime the correct Provider for it along with its connection string. I got to a point where my app would correctly connect from SQL Server to a MySQL DB, but there's a point where the app fails since SubSonic internally generates queries of the form
SELECT * FROM dbo.MyTable
which MySQL doesn't support obviously. I also noticed queries that enclosed table names with brackets ([]), so it seems that there are a number of factors that would limit the use of one Provider along multiple DB engines.
I guess my only other option is to sort it out with multiple generated providers, although I must admit it does not make me comfortable knowing that I'll have N copies of basically the same classes along my project.
I would really love to hear from anyone else if they've had similar experiences. I'll be sure to post my results once I get everything sorted out and working for my project.
Has any of this changed in 3.0? This would definitely be a worthy reason for me to upgrade if life is any easier on this matter...