- What is the difference between ClassMetadata and MappingInfo? It
seems
that the latter is a temporary holder of schema objects until the
final
ClassMetadata is assembled. Is that correct?
Yes. OpenJPA parses from various different formats into MappingInfo
data structures, and then the ClassMetaDatas are created from the
MappingInfo.
- Noticed that the enhancement on class loading is no using the
classes I
created to extend OpenJPA (i.e. Configuration and what follows from
that).
- Also noticed that MetadataRepository is created at least two times
once
when enhancing and once for real.
These are probably related -- the enhancer by default uses a plain
OpenJPAConfigurationImpl instance instead of a JDBCConfigurationImpl
or whatever subclass is available in the environment. In general, the
enhancement contract is simply a way to plug into objects for the
purposes of interacting with their persistent state, and so the back-
end-specific details must not be relevant. IOW, it is a design goal to
be able to support different back-ends for the same enhanced classes.
Is there something that you find that you need to do during
enhancement for your task?
I am planning initially to add a new @Temporal annotation and to
make sure
that this annotation translates into additional columns in the
table, into a
modified primary key and custom handling of the SQL statements. What
would
be the main touch points in the code to make that happen?
What is the goal of your work? Also, is @Temporal targeted at the
class level or the field level, or both?
Assuming that you're looking into adding object versioning support to
OpenJPA, I believe that there are two general approaches that you
should consider:
1. change the ClassMappings (or things they use) to know about
temporal information, and to translate the various Broker-level / EM
APIs to their temporal equivalents (EntityManager.remove() => an
UPDATE statement; modifications => UPDATE / INSERT pairs, add
timestamp range qualifications to queries and relationships, etc.)
2. add a new StoreManager implementation that does the above
translations at the generic object level and delegates to an
underlying StoreManager.
I'm not sure which approach I like the most. #2 seems more natural, as
it operates at the object persistence level, rather than in the JDBC
nitty-gritty. But #1 might be more straightforward to implement, since
there isn't currently a clean and simple way to add synthetic
persistent fields or field-like things to a class, whereas it is
straightforward to do so at the JDBC layer.
-Patrick
On Nov 13, 2008, at 10:04 PM, Yuri wrote:
I started running through a few debugging sessions to understand the
design
and come up for a course of action in terms of extending OpenJPA. A
few
questions came up:
- How can a ProductDerivation be used to extend OpenJPA (I am
assuming that
is its purpose)?
- What is the difference between ProductDerivation.TYPE_PRODUCT and
ProductDerivation.TYPE_FEATURE
- What is the difference between ClassMetadata and MappingInfo? It
seems
that the latter is a temporary holder of schema objects until the
final
ClassMetadata is assembled. Is that correct?
- Noticed that the enhancement on class loading is no using the
classes I
created to extend OpenJPA (i.e. Configuration and what follows from
that).
- Also noticed that MetadataRepository is created at least two times
once
when enhancing and once for real.
I am planning initially to add a new @Temporal annotation and to
make sure
that this annotation translates into additional columns in the
table, into a
modified primary key and custom handling of the SQL statements. What
would
be the main touch points in the code to make that happen?
thanks,
-- yuri
--
View this message in context:
http://n2.nabble.com/Customizing-OpenJPA-tp1497344p1497344.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
--
Patrick Linskey
202 669 5907
