On Mar 2, 2008, at 7:25 PM, Frits Jalvingh wrote:
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?
PreparedStatement caching can be configured outside Cayenne at the
DataSource level. Cayenne by itself doesn't do PreparedStatement
caching and doesn't care about it.
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)?
The later. This is not configurable in Cayenne. I strongly suspect
that PreparedStatement caching is never a bottleneck in the case of
update (and in any event, if we issue a set of different UPDATE
queries for each entity, each variation can be cached just as well).
If somebody can prove me wrong with some profiling data, we can
reconsider the update approach.
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?
Rollback is a local operation. No DB access is performed.
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?
Yes.
4.b Are the values of a persistent object in that DataContext changed
during the commit or rolled back to some earlier state?
No, but the user has a choice to do that if he wants.
4.c Would it be possible to "fix" the values on just the objects that
"failed" in the same context and commit again?
Yes.
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?
It can be done both ways. 'commitChangesToParent' vs. 'commitChanges'.
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.
Yes.
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.
(enhanced) POJO without JPA is in the plans (and partially works
already). But this is not a high priority.
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?
No, absolutely no plans to deprecate Cayenne API. The goal is to keep
both API's on top of the same (existing) Cayenne stack as first class
citizens.
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.
We are implementing an auto-incrementing version as a part of JPA
alignment. So this is coming.
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";
You can achieve that with JPA-like lifecycle callbacks (that are
available in Cayenne outside JPA) - POST_UPDATE, POST_PERSIST.
other databases (Oracle, Postgresql) can return
the changed fields in the same statement (insert xxxx returning yyy).
Hmm... does it get passed over JDBC back to the client, and if so, do
you have a JDBC example? (I know that even the standard callback via
'Statement.getGeneratedKeys()' still doesn't work with many drivers).
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.
As far as restoring the DataContext state, Cayenne should be able to
that.
Andrus
