I’m used to liquibase to generate and maintain my DB.
I would not do it another way anymore.
I try to create generic code I can easilly move to a new DB brand if needed.
But recently I was facing a problem: I have to build an application with Google App Engine.
After some investiagation… I discover that my way of working don’t change a lot in the application.
I “only” need to adapt some part of the code to use the BigTables of Google.
But… so far I know… impossible to reuse liquibase to generate the “repository”.
The same if I want to patch the Data structure… How to apply patches without liquibase.
I have the feeling I have to reinvent the weel.
In a certain point of view, the problems are similar for BigTable than for DB.
So, why not include this functionnality to liquibase ?
IMHO this might be possible only if somebody wrote a JDBC driver for BigTable first. Liquibase depends on the JDBC infrastructure to carry out its functions.
Originally posted by: shantanu_k06
IMHO this *might* be possible only if somebody wrote a JDBC driver for BigTable first. Liquibase depends on the JDBC infrastructure to carry out its functions.
I looked into it a bit at one point with google app engine, and the big problem I ran into right away was a lack of DML statements that can be ran against the database. It seemed that GAE would just create columns and tables as necessary based on your model classes without the chance for you to control how that creation actually happens.
Theoretically, liquibase should be able to be executed against a NoSQL database. With 2.0, you don’t necessarily need a JDBC driver, but it makes it much easier. I would think that NoSQL would need the same sort of schema migration support that a standard database does, but you do need to have some sort of DML statements to run.
