[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dali-dev] Re: help with Dali 2.0 model migration - how do I now get entities?
|
Tom,
I have checked my changes and they will be in next week's WTP ibuild or
you can get the code out of cvs. I'm hoping these changes will solve
your problem. If you still need to debug where classRefs are being
updated take a look at
GenericPersistenceUnit.updateClassRefs(XmlPersistenceUnit)
Karen
Tom Mutdosch wrote:
Yup, we are running a Job with the same scheduling rule. We actually
had this discussion and solution back in September after the Generate
Entities was changed to an async operation, which is how we got things
going back in 1.0).
Sorry - I was mistyping "mappingFileRefs" in my last email. I meant
classRefs(). That is, I'm wondering if I can check for exactly when
the PersistenceUnit.classRefs() is updated with the new entity. Then
I can verify if my Job is somehow running before that intermittently.
Aside from this, I think that the SynchronousJpaProjectUpdater is
helping clear up some of my other problems as you predicted, so thanks.
One other related question: do I later need to set the JpaProject's
updater back to the state that I originally found it in? It seems
like it stays as a SynchronousJpaProjectUpdater on the project after I
set it- would that screw up Dali's views, etc, or do you guys ensure
that it is an asyncUpdater when you need it?
Thanks
Tom
Karen Moore wrote:
I believe the key here is that the entities generation is running in
a job. You can see that in EntitiesGenerator.generate(), it uses a
job with a scheduling rule on the project. The best I can think of is
that your own code needs to run in a job as well with a scheduling
rule on the project, that way it won't run until the entities are
generated.
The implied orm.xml file is set in
GenericPersistenceUnit.setImpliedMappingFileRef(). that is where you
could put a breakpoint.
I'm curious how this worked for you in 1.0? The entities were
generated in a job there as well.
Karen
Tom Mutdosch wrote:
Hi Karen,
Me again (sending directly to your email b/c the Dali dev list keeps
returning my messages). Sorry to keep bugging you :)
After more testing, It looks like the synchronousJpaUpdater is
mostly working, but is sometimes intermittent. Most often, this
happens when I have no entities generated yet in my project, then
generate one, and check the mappingFileRefs() and it comes back
empty. If I repeat the process again, it seems to have better
success and shows both generated entities. Is there any way I could
help debug this? Where could I set a breakpoint for when the new
entity is added to the mappingFileRefs? Then maybe I could ensure
that that is getting called by the time I am later requesting the
files.
Thanks
Tom
Tom Mutdosch wrote:
Thanks Karen,
Cool, that sounds promising. I gave it a try and set the
JpaProject with a SynchrounousJpaUpdater before calling out to the
GenerateEntitiesAction. When I finished the action, my code gets
control back and I immediately call
persistenceUnit.mappingFileRefs(). This still does not contain the
entities that were generated with the GenerateEntities wizard. I
paused the thread at that point and checked the persistence.xml
file on the filesystem and it had not yet been updated with the new
entities at that time either. Should the call to mappingFileRefs
be blocking until the new entities are added into the model? It
seems like there is still some sort of threading issue that I'm
maybe running into? Do I need to do anything else besides simply
creating a new Updater and setting it on the project?
Thanks
Tom
Karen Moore wrote:
Tom,
I think you should take a look at JpaProject.Updater and the
Synchronous and Asynchronous implementations. For UI development
we are using the Asynchronous updater, but since you are doing
internal modifications I believe you are going to want the
synchronous updater so that when you make context model changes
the project is updated before you continue making changes.
Also, the code I gave you looks at PersistenceUnit.classRefs()
which includes both specifiedClassRefs (those listed directly in
the persistence.xml) and impliedClassRefs (those not listed, but
that are defaulted in based on your JpaProject 'discovers
annotated classes' setting). This is a pardigm we've have followed
throughout our context model. I would imagine the problem is
because the project Update thread is not completed yet. The
update will run, updating our context model from the underlying
resources and settings defaults based on other settings in the
model. Any change that occurs will cause another run of the
update job to be queued up (actually, it will run again once it is
finished based on whether any changes have occurred, not for every
change that occurs). So, if you used the synchronous project
updater, you will not have to worry about there being a separate
update thread. In our tests we use the synchronous project updater.
I believe this will also solve some of the bugs you have just
entered this afternoon.
Hope this helps!
Karen
Tom Mutdosch wrote:
Hi Karen,
I tried the getEntities() code snippet that you had sent me, and
it works mostly but does not do exactly what I expected. That
seems to only retrieve entities that are listed directly in the
persistence.xml file, and not annotated Java entities that aren't
explicitly listed. We actually discovered this due to an
apparent timing bug where immediately after the Generate Entities
wizard was run we called our getEntities() method and it was not
returning the new entity classes. (Aside: it looks like there's
a separate timing issue here where the entities were not yet
updated in the persistence.xml; Is the synchronizeClasses run as
a separate Job after GenerateEntities?)
In any case, is there a way to do a similar getEntities() call
that gets entities from the Dali model whether they are listed in
the persistence.xml or not? It looks like calling
jpaProject.annotatedClasses() returns all of the entities as
ITypes, so it seems they are stored in the model somehow - I'm
just not sure how to appropriately get all of the PersistentTypes.
Thanks
Tom
Karen Moore wrote:
I agree, the code to get a list of entities is a bit convoluted
and difficult to find. We've had other adopters ask us for this
as well, so documentation on the existing API or helper API is
the way to go. Thanks for your feedback!
Karen
Tom Mutdosch wrote:
Hi Karen,
Thanks for the details; I definitely understand all the
complexities in providing various API to suit every possible
need. I have no problem writing a getEntities() method
myself. The main reason I suggested it was that it wasn't
totally obvious how to do that using the existing APIs. I
figured others might have the same difficulties, so a new API
call could address that. But having documentation or examples
of how to do some of these common operations would probably
help achieve the same effect, so maybe it's not a big deal.
Regarding saving the OrmXML and PersistenceXML models, thanks
for the code snippets - that's what I was looking for. I
opened an enhancement request with my particular usecase:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=223197
Thanks again,
Tom
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
