Hi Lukas,
On 18/12/2012 4:16 AM, Lukas Eder wrote:
Every record would hold one more reference (or null), which is OK. But
I'm not such a big fan of adding one additional reference to every
org.jooq.impl.Value object. Maybe there is a simpler implementation,
that doesn't need one reference per value.
Do all the "setValue" calls go through the record object? or can it
happen directly on the value object?
Can these listeners go in UpdatableRecordImpl instead of the base Record
class?
Getting a bit off topic... The more I have been using JOOQ, the more things
I keep wanting to add to it. It is a great project. It has really changed
the architecture of my system. It eliminates a lot of the data layer and
makes it a whole lot more agile. It would be great to be able to plug into
it in all kinds of places. So for me the more extension and plugin points
the better. I still want to implement an audit trail system, an extensive
validation system and a trigger system that all runs through JOOQ.
Nothing that ExecuteListener could help you with, so far? I'm open to
any more detailed elaboration of your ideas!
Yes, my plan is to use the execute listener and parse the SQL statement
to get Tables / Fields updated. It would be great if the update
initiated from an UpdatableRecord to actually pass that record, or if it
was an Update statement then to pass the fields in the statement. It
would save me parsing the SQL :). I know you can write SQL in JOOQ, but
if this additional information available then I could use it in preference.
I'll prevent certain queries from being issued that affect certain
tables. (eg. can't run a merge statement, for some tables only a single
record can be updated at a time). It will impose some restrictions, but
If I did this through a DAO it would impose restrictions anyway. Tables
I am running a MERGE on, I probably wouldn't want to keep an audit trail
for every record anyway...
The execute listener will store all the changes until a transaction is
committed, then before it is committed it can be run through other
systems, eg. validation, generating audit trails. That way it can all
happen as part of the same transaction and I can make sure the database
will be in a "correct" state when the transaction is committed. eg.
Record A requires certain records in Record B to make sense. So on
committing anything that affects record A, it can check the
corresponding records in B are valid in the same transaction. I'm using
MVCC in the database, otherwise this probably wouldn't work
consistently. It also means I can define some hard complex validation
rules and I know they will always be enforced, because all updates run
through the execute listener.
Also this way instead of running everything through a DAO and having
heaps of boilerplate code to maintain, I can pipe it through that
central location and then define elsewhere any constraints, audit trail
generation, etc. I'm also planning on trying to catch updates prior to
JOOQ executing them on the database to do "pre execution validation and
triggers", but this is really outside of the scope of JOOQ. I'm
basically just storing up a bunch of UpdatableRecord objects, then
commit them all at once after running some checks and triggers on the
records as a set. For instance a certain object might require a "reason"
for being changed. So in this check, it will detect that it needs a
"reason", so pop up asking for a reason, then once satisfied it will run
the commit.
I think it will work :). I'll see once I've implemented it. I'm just
sick of applications that have DAOs everywhere, then on changing a table
structure slightly I have to update it in 10 places. Then I forget to
update it somewhere and find out a few months later... Also, devs can
really easily circumvent constraints. If it all pipes through though
JOOQ then I can catch everything there. I've done a similar thing using
Hibernate, but it was a bit messy, and hibernate is an ORM.
Also, all write access to the database access goes through the
application, so I don't have to worry about defining too many things at
a database level. Otherwise I'd be using stored procedures for
everything and have most of the logic / validation / triggers / etc in
the database. I'd rather define and maintain it in java.
All part of my quest to try and make the data layer a whole lot easier
to change and maintain. So far going well. I keep restructuring tables
over and over. I have been implementing some basic DAOs where re-using
the same complex query, but they are quite easy to maintain.
Anyway, once I have it working (hopefully!) I'll let you know if it
works, or if it is fundamentally floored and was never going to work.
Thanks, Ryan
