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
This archive was generated by hypermail 2.0.0 : Sun Mar 02 2008 - 14:11:47 EST