[
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 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
