Is there a way of having liquibase call a custom Java class/plugin and giving that class access to the underlying connection to make data changes. I had a look but it only
So of our update steps require extensive data manipulation which is far far easier to do and debug in code than using SQL. So I would want to write tasks that can extract, transform and save data. Is that possible within the liquibase framework?
If you are using a subclass of Change using the extension framework (liquibase.org/extensions) the generateStatements() method is passed the Database object the change is being executed against. Calling
((JdbcConnection) Database.getConnection()).getUnderlyingConnection()
will return the java.sql.Connection used.
If you are using the CustomTaskChange interface, the execute() method that is executed is passed the same Database object you can get the connection from.
Related
I'm trying to figure out a way to serialize an activejdbc model from a server application running on a JVM across the wire to another JVM that is running a GUI application. The GUI application does not have access to the database, since it is not on the same machine. On the GUI, when I try to set the properties on that model instance via a setter, to update some fields to send the model back to the server to be updated, I obviously get exceptions about not having a database connection.
I have a way to get around this by overriding the getMetaModeLocal() method, but was wondering if there was a cleaner solution to this?
The exception is as follows:
Caused by: org.javalite.activejdbc.DBException: Failed to retrieve metadata from DB, connection: 'default' is not available
at org.javalite.activejdbc.Registry.init(Registry.java:133)
at org.javalite.activejdbc.Model.getMetaModel(Model.java:67)
I expect to be able to update the model without having to have a database connection until saveIt() has been called.
You have two options for this:
Do not use models in your GUI app. On the server side you can serialize models into Maps by using a Model.toMap() method and simply sending a map to the UI. If you need to make updates, you can set new values to that same map and then send it back to the server side, where you can use a model.fromMap(map).save() approach. In other words, no need to send models across the wire.
Wait till this is fixed: Add ability to use model classes without connecting to the DB. This new feature is currently in active development, and completion is projected within a couple of weeks. It will allow you to pass models from one JVM to another without the database because the DB schema will be queried during the build rather than at run time.
Is there any way to reset the autoincremental counter for a field annotated with #id? We are trying to test our repositories and it would be really helpful in order to have a database in an empty state.
Test set up
We have an utility class that provides a singleton instance of the database connection. For each test class, we obtain that instance.
Once obtained, before executing each test, we set the initial DB state (delete all previous DB data and execute the inserts for the initial data).
We're following the same pattern that we've used with MySQL in order to avoid the DB creation on each test but maybe that's not the best way to test objectbox repositories.
I've seen that there is a method that allows to delete all files from the DB but it requires to have all the DB connections closed.
The preferred way for ObjectBox unit tests is actually to close the store and delete files. There's no concept of a "connection" to a database.
Here is a JUnit base class taking care of everything:
https://docs.objectbox.io/android-local-unit-tests#base-class-for-tests
I want to have single FakeApplication for all my test.
My final goal is to set up database and use it in all test. They should access single database and share data in it. I can not use H2, because I use some MySQL features(fulltest search, for example). But if there is no started application, I can't call "DB.withTransaction" because there is started application yet. But it should start once, because it drops all tables and create new ones.
How can I do it?
I am using scala and JUnit. I solved my problem next way: I just created singleton for my fake application, which is retrieved as an implicit val. So, all work about creating and cleaning database is done on first fetch.
When I Add-Migration, I get the appropriate DbMigration class with the Up / Down methods, where I am able to make schema changes and (with the use of the Sql() method) can make data/content changes as well.
I'd like to be able to make content changes per migration using the database context. I understand that I could use the Seed method in a Configuration class, but my understanding is that I can only wire up one Configuration with my initializer.
I'd prefer to have a UpCompleted()/DownCompleted() methods that would provide access to the db context after the migration completed. This would enable writing incremental data/context change "scripts" in a manner that would be less prone to errors than using the Sql() method.
Am I missing something? Is this possible?
Thanks!
That doesn't really work because the context only has your most recent model - which can only be used to access the database once the most recent migration has run (which is effectively what Seed achieves).
For an example of how this idea breaks, if you moved a property from one class to another then seed logic from older migrations would no longer compile. But you couldn't change it to use the new property because the corresponding column wouldn't exist in the database yet.
If you want to write this kind of seed/data-manipulation logic, you need to put it at the end of the Up/Down methods and use the Sql method to perform it using raw SQL.
~Rowan
I'm looking into adding some unit tests for some classes in my data access layer and I'm looking at an update routine that has no return value. It simply updates a row based on the id you provide at whichever column name you provide.
Inside of this method, we collect the parameters and pass them to a helper routine which calls the stored procedure to update the table.
Is there a recommended approach for how to do unit testing in such a scenario? I'm having a hard time thinking of a test that wouldn't depend on other methods.
Test the method that reads the data from the database, first.
Then you can call the update function, and use the function that was tested above, to verify that the value that was updated is correct.
I tend to use other methods in my unit tests as long as I have tests that also test those that were called.
If your helper functions are in the database (stored procedures or functions) then just test those with a DatabaseUnitTest first, then test the visual basic code.
I would just use a lookup method to validate that the data was properly updated.
Yes, technically this would relay on the lookup method working properly, but I don't think you necessarily have to avoid that dependency. Just make sure the lookup method is tested as well.
I would use the method to get that data and check the return value to what you updated and Assert the expected value. This does assume the method used to retrieve the data has been tested and works correctly.
I use nhibernate and transactions and for unittests I don't commit to the database but I flush the session which gives the same errors if needed but doesn't write the data.
Of course if you have a build server you just run the unittests against a freshly made database which is freshly made on each build. Try using an filebased database like firebird or something.