Hello there,
I am evaluating Cayenne for use in a new project. I have read the
documentation and experimented a bit but I'm left with a few questions.
I hope I can get some answers here ;-)
1. When Cayenne accesses the database, are PreparedStatements used (and
cached) within a single DataContext? That is: if code causes 100x the
same SQL to be generated and executed (select xxx from yyy where id=?)
is this prepare once, cached and only executed multiple time or is it
fully created every time?
2. When Cayenne executes updates does it update the entire record or
does it only update the fields that changed? If it's the latter case:
can it be disabled to always update the full record (to allow
for statement caching - if available)?
3. The documentation states that when you call rollbackChanges() a
transaction the DataContext state is restored to the state it had
before. Does it do this by using "copies" of the objects it has read
or is the database re-queried?
4. What happens if data gets commited to the database and a SQLException
occurs (like "duplicate key", "null in non-null column" etc?
Specifically:
4.a Is the state of the DataContext once such an error occurs still
usable?
4.b Are the values of a persistent object in that DataContext changed
during the commit or rolled back to some earlier state?
4.c Would it be possible to "fix" the values on just the objects that
"failed" in the same context and commit again?
5. When using "nested" DataContext, if you commit to the "upper"
DataContext I expect that the changes are only propagated to the Object
Store in that upper context, not to the database. Is that correct?
6. The current implementation uses generated base classes to contain
Cayenne-specific code. JPA implementations need something like
bytecode-generation (proxies) to add code to persistent classes
as JPA-defined classes need no platform-specific base class. So I assume
that the JPA variant of Cayenne will have something like that. Are there
plans to extend this to the Cayenne-specific interface?
I would not want to use JPA because it sucks bigtime, but having clean
classes is a wish.
7. The project is currently busy supporting the JPA standard. Is it the
vision of this project to become a JPA provider mainly and deprecate the
own interfaces? If Cayenne would become a JPA implementation only it
would not be the correct choice for my project since that standard is a
lousy one.
8. If I would select Cayenne for my project I would need to add some
features to it. The reason is that I will access an already-existing
legacy database with lots of oddities like triggers and stuff.
Specifically:
a. I would need to add an alternative version of "Optimistic locking"
where a specific field in the database would hold a timestamp or version
number. This number should be maintained by Cayenne i.e. incremented as
soon as Cayenne inserts/updates the record. It would also be used in the
where for updates/deletes exactly like the current optimistic locking
mechanism to check for changes at that time.
This also has another consequence (8.c)
b. I would need support for database-generated fields at update and
insert time. I must be able to mark fields as "generated at update,
generated at insert or both". Cayenne should retrieve these fields
after inserting/updating a record to keep the Object representation
in-sync with the database. For some databases this would require a
"select after update"; other databases (Oracle, Postgresql) can return
the changed fields in the same statement (insert xxxx returning yyy).
This also requires 8.c:
c. Both these changes require that all generated fields get copied and
stored within a database commit so that the original values (before the
commit) can be restored when flushing data to the database fails; this
is needed to keep the DataContext consistent after a commit failure.
Are these extensions doable without rewriting the entire
implementation;-)? Would these changes be acceptable to be incorporated
in Cayenne?
Lots of questions,I know.. I hope someone can find some time to help me
by answering them!!!
Thanks in advance for your time,
Frits Jalvingh
This archive was generated by hypermail 2.0.0 : Sun Mar 02 2008 - 12:26:16 EST