With the DataTable, you can also run queries on it, sort it, define
parent child relationships (aka Foreign Key) with other data tables, it
stores history of changes, create views of it, have listeners on data
change (I think). It is like an in memory database pretty much. I think
the similarities to a JDBC result set end at the idea of having rows and
columns.
I don't think a DataTable works in "eager" mode. It works offline, a
changeset is calculated and applied to the database.
Bear in mind I haven't used this for about 6 years :), but I often find
a lot of good ideas in the .Net world. Even if my preference is Java.
Regaring the .remove() functionality you mentioned, I've implemented
something similar in my project where records not yet in the database,
if .remove() is called they are just discarded client side. If they are
in the database, then the .remove() when flushed will execute a DELETE
on the database (first with an optimistic locking check). This kind of
functionality built in would be great. It would save implementing all
the logic and "tracking" my records.
Thanks, Ryan
On 25/02/2013 5:13 PM, Lukas Eder wrote:
Slow and lots of consideration sounds like a good idea.
OK then. That means that for now, you'll have to store "changed" flags
and "original" values externally somewhere in your application, once
you migrate to jOOQ 3.0
I can't remember enough of ADO.net to remember it in much detail :). I just
remember liking the "DataTable" object, it was like having an in-memory copy
of a view of the database that you could "sync" back after you had changed.
Quite a simple concept, but very powerful. I'm just always surprised to have
never found a Java "DataTable".
Well, a JDBC ResultSet is a "DataTable" in a way. Only, the API is
really very awkward, as you have to position an index in a cursor
first, every time you want to modify a cell at position (x, y)
I guess because JOOQ knows all the keys and
references, is typesafe and has "Tables" in Java, it is half way there to
the DataTable.
I see, yes that sounds much like what I've had in mind recently.
org.jooq.Result could work in an "lazy" and "eager" sync mode.
- "lazy" means that you have to explicitly "flush" changes to the DB.
This probably includes List operations, such as Result.remove(), which
have to be flushed as delete operations. I'll have to think about this
again. There are lots of corner-cases, I guess. I have now registered
this as https://github.com/jOOQ/jOOQ/issues/2265
- "eager" means that you have to fetch a Result using
fetchUpdatable(). This would set the JDBC ResultSet.CONCUR_UPDATABLE
flag, allowing for creating an "online" JDBC ResultSet / cursor, where
the various ResultSet.updateXXX() methods can be used internally, by
jOOQ, every time a record from this result is changed. This is already
registered as https://github.com/jOOQ/jOOQ/issues/1846
I'll do some further reading in the MSDN docs, to see what this
DataTable is all about.
Anyway, I'm a bit out of touch, I haven't been working on enough different
projects lately to remember all the good and bad points of the various
technologies :)
Well anyway, it's good to bring those impressions here :-) There's
always some good idea to take inspiration from
Cheers
Lukas
--
You received this message because you are subscribed to the Google Groups "jOOQ User
Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
