- now the currentVersions are queried later, because only after the
realm handler is started, can we query the current version.
- this lead to only parsing the migrations at initialize
- and thus in start querying the versions and performing the required
migrations
- If a code migration is run programmatically, then in some migrations
shouldn't fail if a realm is missing -> the realm might not be available
in a certain environment
- We have to re-think this. It does not work, throwing an exception if
commands are registered on a read-only TX as then we don't know if we
want to roll back or not - we probably need a ROLLBACK_ON_ERROR or
something, indicating that we are preparing a non-read-only TX.
- currently the parsing of the versions is handled
- missing is the actual loading of the date into the realms
- and the performing of the code migrations
- and the registering of the performed migrations
- Now if you need to perform commands to carry on in your transaction,
you can simply use the tx.flush()-method.
- Should something go wrong, then even after a tx.flush() one can call
throw tx.fail("Reason") or tx.rollbackOnClose()
- So sadly just auto closing a TX using try-resource from Java7 is a bad idea.
- Doing that leads to problems when an exception is thrown, then the close is called (duh) but this leads to commit being called.
- Since the Java language does not offer a decent way to detect if the close is being called in the context of an exception i was forced to add a tx.commitOnClose() and tx.rollbackOnClose().
- The default is that when a TX is opened, then the close strategy is rollback; the API user must call tx.commitOnClose() before the TX is closed by the braces, or as late as possible, to make sure that if an exception is thrown the transaction is rolled back, and not committed.
- The API was also extended with a tx.fail(msg):StrolchTransactionException so that if the implementor detects an unrecoverable error, one can write: throw tx.fail(“my reason”);
This was sadly an unavoidable late 1.0.0 change
Conflicts:
li.strolch.agent/src/main/java/li/strolch/persistence/api/AbstractTransaction.java
- So sadly just auto closing a TX using try-resource from Java7 is a bad idea.
- Doing that leads to problems when an exception is thrown, then the close is called (duh) but this leads to commit being called.
- Since the Java language does not offer a decent way to detect if the close is being called in the context of an exception i was forced to add a tx.commitOnClose() and tx.rollbackOnClose().
- The default is that when a TX is opened, then the close strategy is rollback; the API user must call tx.commitOnClose() before the TX is closed by the braces, or as late as possible, to make sure that if an exception is thrown the transaction is rolled back, and not committed.
- The API was also extended with a tx.fail(msg):StrolchTransactionException so that if the implementor detects an unrecoverable error, one can write: throw tx.fail(“my reason”);
This was sadly an unavoidable late 1.0.0 change
- this was a big issue as the query was delegated by the TX to the
persistence handler, which meant that the current element map types
(cached, transactional, etc.) were ignored. Move the doQuery to the
element maps, and this lead to also reimplementing the way the cached
element maps work: they now use an in memory dao, instead of MapOfMaps
Robert von Burg