since a while I've been collecting some thoughts what to do next for Persistence Extension in form of a mind map and it's quite growing. So I believe it's just about the time to ask for your help with prioritizing and to brainstorm about the next great features.
So, here are the areas which I was thinking about:
Scriptable Data Sets
- Adding dynamic flavour to your data sets by using any language supporting JSR 223 (starting let's say with JRuby and Groovy).
- Might be helpful when dealing for instance with time-sensitive data. For example you can define last login date for yesterday using Groovy
- firstname: Clark
lastlogin: "groovy:new Date().previous()"
- Another thing (just an idea as for now) is to have possibility to verify relationships easier. Since ids are generated during the test execution it's not really the best approach to assume something about them. Would be much more convenient to use some sort of business key to reference to the other rows / entities. Let me show you possiblle approach for @ShouldMatchDataSet:
- firstname: Clark
- streetname: "Luthor Street"
- streetname: "Kryptonite Street"
- useraccount_id: ref(useraccount[firstname="Clark",lastname="Kent"])
addresses_id: ref(address[streetname="Kryptonite Street",houseNumber=7,city="Metropolis",zipCode=1234])
Entity / object oriented way of defining data sets
DBUnit data sets are great, but they are really low-level, row oriented description of the data. As alternative I was thinking about providing YAML / JSON based representation of the objects, so something like:
- id: 1
- id: 1
streetname: "Kryptonite Street"
- id: 2
streetname: "Luthor Street"
Test Data Generation
Possibly by simple integration with one of the tools:
Integration with DB migration tools
Hibernate schema auto-creation feature is simply great for prototyping and testing, but for living application it's sometimes not enough. Hence there is quite a bit of migration tools available for Java project, such as
Why we should integrate it with Arquillian Persistence Extension? I see at least these reasons:
- As replacement for Hibernate / SQL schema creation (create-drop or custom scripts). Additional value would be to quickly check if your migration scripts are valid (also some sort of integration. to assure that your whole process of deploying the new version will work smoothly).
- Some of the tools, such as Liquibase, offers db insertions. So people can use the format which is already familiar for them instead of DBunit data sets.
This might actually result with some nice module split and introduce extension mechanism (yeah, extensions of extension), so we can end up having following structure:
- Unitils has nice utility assertion to verify if JPA mapping is consitent
- Support for NoSQL (might be quite a nice journey )?
Looking forward to your feedback!