Thanks.
So after a quick glance it seems that the firing of constraints is very
nicely concentrated.
Only table.fireBeforeRow and table.fireAfterRow call it.
The signature is
fireConstraints(Session session, Row oldRow, Row newRow, boolean before)
The important ones are oldRow and newRow.
So if someone would like to move the constraint check to the end of
transaction
one would need to create some kind of changeset caused by the transaction.
The simple way to do it would be
List<Row> oldRows, List<Row> newRows
that would simply be a list of rows that have been somehow affected by
the transaction.
These lists could be populated in the same place where the constraints
are now being checked.
And then at commit time the constraints could be actually checked.
And for all you speed freaks this could actually increase speed because
now the constraints
are checked twice for every statement (before and after the statement).
Doing it at transaction boundary
would require running them only once :-)
Comments?
Should I give this a shot?
- Rami
Sergi Vladykin wrote:
See org.h2.table.Table.fireConstraints(...) method
On 25 ноя, 22:57, Rami <[email protected]> wrote:
Sergi,
Do you know where in the source the constraint check is done?
I tried to follow quickly from Session to Command to Table to Index but
I must have missed the constraint checks.
All other constraints (except NOT NULL) seem to inherit from a common
root (Constraint) which is a good sign :-)
- rami
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
