[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] question about composite persistence unit
|
Comments inline:
On 06/03/2012 11:27 PM, Geronimo Ma. Hernandez wrote:
Hello,
On Tuesday 06 March 2012 - 15:25:50, Tom Ware wrote:
On 03/03/2012 1:39 AM, Geronimo Ma. Hernandez wrote:
I don't need Assistance on how to write a MetaDataSource. The point is, I
don't know how to bring it into play.
The extended XML is used any time a new EntityManagerFactory is created or
on a call to EntityManagerFactory.refreshMetadata() - that method is
EclipseLink-specific, so you'll have to unwrap your factory to use it.
That call hits the right direction, but I fear it is not what I'm looking for.
I looked at the source of refreshMetadata and if I got it right, entity-names
will not be read from given properties.
So may I ask for an extension, where a provider for the list of entities may
be injected?
Please feel free to log an enhancement request and provide a detailed
explanation of what you need. What I am hoping to do in this thread is help you
get going without such an extension since even in the best case, it will be some
time before we can implement such an extension.
The situation I imagine is one where you have a default persistence unit that
lists your base classes. When you want to extend your persistence unit, you
call refreshMetadata(Properties) and include a property that points at a way to
get an orm.xml file. In that ORM.xml file, you simply list the new entities you
want included in your persistence unit and any mappings to them in your existing
entities. It is not clear to me how this is different from what you are asking.
Please provide an explanation of that in your enhancement request.
Note: The refreshMetadata() method is on EntityManagerFactory and not
EntityManager. If you are dynamically extending your entities, you won't
be able to use the same EntityManager to operate on the extended entities.
Instead, you call refreshMetadata() and from then on every EntityManager
you obtain from the EntityManagerFactory will use the extended entities.
Previously created EntityManagers will use the old mappings.
That behavior is quite ok.
I could take the entities from old EntityManager and "merge" them into a new
one.
Persistence (in my app) is an application service, coded in core app and
published as a service - so all extensions will use the same application-
session from authentication.
I dived into the eclipselink sources and found a
EntityManagerSetupImpl.updateDescriptorCacheSettings(...) - I know,
that's internal stuff, but is there a way to trigger that call (or
similar action) from application?
What is your goal in calling this method?
Not especially this method, but I believe, a way to provide the list of
entities on refreshMetadata would be the right way in RCP-environments.
I think, the url-way is not appropriate for RCP-environments. Even if that app
would use networking, the list of entities to support is a local question, so
no webservice can give the right answer.
Using urls in RCP-environment is not appropriate for local information. Better
would be a possibility, where a provider could be injected to
EntityManagerFactory, which gets asked for the list of entities each time
refreshMetadata is executed.
If no Provider has been injected, the current behavior can serve as a
fallback.
I am not sure what you mean by injecting a provider, but another option in the
refreshMetadata(Properties) call is providing the classname of a class that is
called to get the new metadata. That class is a class you implement yourself.
I could imagine a Properties instance in my app, which gets extended by
extension-plugin activation and for so always holds the pool of known
entity- names.
Binding that PropertyMap to a Handler of the EntityDescriptorCache,
dynamic change of supported classes could be established.
Don't know how weaving interferes this game, but using static weaving
should make the binaries fit into dynamic play. Can I trigger weaving at
build- process?
I'm not sure I understand the two paragraphs above.
Well, in OSGi or Eclipse-RCP environments the activation of plugins is not
determined. They got loaded on demand and the only trigger is a possibly
registered Activator.
If I use an Activator, that registers the provided entities of that plugin to
a central EntityRegistry, the ApplicationSession (which holds the
EntityManagerFactory and is used to decouple app from persistence) can use
timestamps to check, whether a refresh of metadata would be necessary.
If that EntityRegistry implements the interface "ListOfEntityProvider" (or the
like) it could be injected to EntityManagerFactory and each time a refresh is
triggered, it will be called for the current list of supported Entities.
I think, this could be a pragmatic way to handle dynamic changes of known
entities.
I additionally vote for extending the EntityManager to allow the usage of
ConnectionPools in Client-environments too.
In RCP-apps it would be very nice, if a long running persistence job could be
run in background and the app continue without any restrictions.
EntityManager does allow the use of connection pools. EntityManager is
analagous to our ClientSession. A ClientSession does all its database access
through a ServerSession. The ServerSession supports connection pooling.
EntityManager/ClientSession never access the database directly.
kind regards
Gero
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
