[
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?
|
Hi Tom,
I'm glad scheduling the SynchronizeClassJob outside of the
GeneratorEntitiesJob did the trick for you. Having not touched this
code in a while, that certainly made a lot more sense than what I did
originally :)
Without looking too closely, your solution with the Updaters sounds
reasonable. When I look at bug 223418 (hopefully for M6) I will take a
look at this and let you know if there is a better approach.
Karen
Tom Mutdosch wrote:
Hi Karen,
I am running with the latest CVS updates (from this morning) and your
updates for the Job seem to do the trick. When I use a
SynchronousUpdater, it definitely looks like I'm always getting back
newly-created entities when I ask for them after a GenerateEntities
action. So thanks for that.
So just for clarification, when I launch Dali's GenerateEntities
action and I want to ensure that the newly created entites are in the
model before I request it, I definitely need to use a SyncUpdater,
right? Then after that, I want to perform some operations on the
entity models (maybe setting the IdMapping, etc) so at that point I
would set the NullUpdater? Then after I have made all of my updates,
I would set it back to the original AsyncUpdater?
I tried this out and it seemed to work, though I still was getting
that NPE (bug 223418) when I used the NullUpdater (only if I use a
SynchronousUpdater do I not see that NPE), but it did not seem to have
any effect that I could see. Does all of this seem like a reasonable
strategy?
Thanks
Tom
Karen Moore wrote:
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
_______________________________________________
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