first of all - I love Jailer, thanks for this neat piece of software :-)
It would be even nicer if there is a possibility to (bulk) disable optional dependencies (nullable FK columns). Is it possible to detect those cases via your db introspection process?
You seem to have CSS turned off.
Please don't fill out this field.
thanks for your praise :-)
It's possible to disable all non-dependencies (Edit->disable all).
I am unsure in which cases it makes sense to disable optional dependencies. Can you give me an example?
> thanks for your praise :-)
you're welcome :)
> It's possible to disable all non-dependencies (Edit->disable all).
yeah, but I specifically want to talk about dependencies (which are optional/nullable indeed)
> I am unsure in which cases it makes sense to disable optional dependencies. Can you give me an example?
of course :)
We extensivly use Jailer to extract data from a huge database (containing a lot of tables). Nowadays this database contains test data created by the business unit. We had a lot of issues regarding our JUnit test quality caused by invalid development test data. Guess what - all tests were green, coverage was above 85% but most of our JUnit tests simply didn't match business requirements and weren't that meaningful.
OK - now we extract test data via Jailer which are correct (from a business point of view) and create JUnit integration for the most critical use cases utilizing the dbunit export function of Jailer. Tailoring test data via Jailer is compfortable but would even be more compfortable ;) if there would be something to detect/visualize/disable optional dependencies to keep the dbunit exports as short and focused as possible to increase readability and maintenability of our JUnit tests.
First of all I would like to define what I think an "optional dependency" is.
If a table A has a nullable foreign key column referencing the PK in table B, then the reference from A to B is an "optional dependency".
Why would you like to disable these dependencies? If you export a row in A with a non-null FK, you wouldn't be able to import it due to FK constraint violations (because referenced B-rows are missing). OTAH, if all FKs in A are null, it wouldn't make a difference whether or not the dependency is disabled.
Of course - you're absolutely right. It wouldn't make sense to disable optional dependencies (if they actually exist) because FK-Constraints aren't satisfied. But wouldn't it be possible to simply ignore those optional dependencies on dbunit export? It would be really nice to create slim and sleek exports for JUnittest because some optional dependencies are simply not relevant. Any visual hint (maybe another color than red or green) is also very appreciated for optional dependencies.
> But wouldn't it be possible to simply ignore those optional dependencies on dbunit export?
Let me explain what this means in more detail:
1. table A has an optional/nullable constraint to table B
2. test data contains one A entity referencing one B entity
3. developer has to create a JUnit test covering some business logic performed on A entities and any B relations simply don't matter
4. developer creates an extraction model with some really cool new feature of jailer where it is possible to see optional dependencies and disable those optional constraints
5. jailer's extraction algorithm detects the disabled optional dependency and simply puts <NULL> into relevant columns
6. developer is happy
:-) :-) :-)
Hm, no further comments?
Sorry for the late answer.
Why don't you simply remove all associations from data model, which are irrelevant for the unit tests? You should then also delete the corresponding FK-columns, or use filters to put <null> into them.
Sign up for the SourceForge newsletter: