Add ability to clean the DB #15827
Add ability to clean the DB #15827
Conversation
quarkus-bot
bot
added
area/hibernate-orm
stuartwdouglas
force-pushed
the
clean-databases
branch
from
cecdcc4 to
790fe07
Compare
stuartwdouglas
force-pushed
the
clean-databases
branch
from
790fe07 to
24f7b8d
Compare
stuartwdouglas
force-pushed
the
clean-databases
branch
2 times, most recently
from
e16231a to
ca1974f
Compare
|
This feature looks nice! I have two questions:
|
|
Nice! Are you aware of #14240? |
| for (DatabaseSchemaProvider i : dbs) { | ||
| i.resetDatabase(name); | ||
| } | ||
| flashMessage(event, "Action invoked"); |
There was a problem hiding this comment.
| flashMessage(event, "Action invoked"); | |
| flashMessage(event, "Database "+name+" reset"); |
| //generate the annotated interceptor with gizmo | ||
| //all the logic is in the parent, but we don't have access to the | ||
| //binding annotation here | ||
| try (ClassCreator c = ClassCreator.builder() |
There was a problem hiding this comment.
The shit we do to deal with modularity :(
| RestAssured.when().get("/my-entity/count").then().body(is("2")); | ||
| RestAssured.when().get("/my-entity/add").then().body(is("MyEntity:added")); | ||
| RestAssured.when().get("/my-entity/count").then().body(is("3")); | ||
| RestAssured.with() |
There was a problem hiding this comment.
I never realised that tests could access dev mode actions.
|
That PR is awesome! I do agree with @yrodiere that I was expecting the DB to be cleaned before my tests. And also that a similar mechanism could be added for other things like caches, but I guess that this can wait until later. |
|
nice! We'll have to be careful to allow us to be smart under the hood though, as some DBs are painfully slow to deal with schema changes; just yesterday on the ORM zulip channels we were talking about a (TBD) feature which could drop the data only rather than removing and re-creating the schema. |
|
I would expect tests to leave the DB in a consistent state by default, so there should be no need to clean up beforehand. This annotation is basically saying 'I am going to leave the DB in an inconsistent state, I want you to clean it up for me' |
- In tests this is done via @CleanDatabase - In dev mode this is done from the dev console Fixes quarkusio#583
stuartwdouglas
force-pushed
the
clean-databases
branch
from
ca1974f to
3861cf1
Compare
|
Sometimes, it can be handy to check in the DB what the test has left behind without having to debug it. |
If we assume that this annotation is only useful within the scope of a single test class, because every test class always resets the database(s) before executing, then yes I agree. Otherwise, I'm afraid that's wishful thinking: people will end up in a situation where the DB is in an inconsistent state eventually. Be it because the application crashed during the last test execution (OOM, stackoverflow), because you stopped the JVM while debugging, ... Also... what do you think about changing the name to allow it to cover non-DB cleanups in the future? |
That's optimistic at best ;) In practice I always have some tests that don't give a damn about the initial state of the DB, so they can all run without any cleanup. And then some really care and need a clean DB before them. It's true that I could fix both tests by cleaning up after them. BTW, is there a way to tell a test class to cleanup after all tests versus after each test? |
|
Because this is an interceptor I can't really do 'after the class', only 'after each method', it would need a different implementation if we were going to support the 'after class' approach. I have also been thinking about native tests, and what we can do to support it. It's a lot more complex, as you don't really want a way for the test to trigger a reset of the DB (as this could be a huge security issue, if there is a way to tell a production instance to clean the production DB). |
|
I have opened #19312 for just the Dev UI part |
|
Closing this, as support for added to the dev console |
Fixes #583