[
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?
|
Hey Tom,
How quickly I forget that we had many similar discussions in the fall :)
I'm changing a few things about how you set the Updater and will check
those changes in today. Brian is going to investigate the problems that
might occur if the AsynchronousUpdater is running at the time that you
set the SynchronousUpdater. It sounds like you need to use the Null
Updater instead (Updater.Null.instance()) . Then when you have
completed your model changes you can set the Updater back to what it was
before and the update will run at that point. Of course this is all
different from the other api you are using
setThreadLocalModifySharedDocumentCommandExecutor where you don't have
to set it back since it's thread local.
The other thing I'm changing is I'm making the SynchronizeClassJob into
a WorkspaceJob and running it after the GenerateEntitiesRunnable.
Currently it's being run from within the GenerateEntitiesRunnable which
seems it could cause problems with you scheduling your own job. This
way those 2 jobs are scheduled before you can schedule yours. I also
realized the synchronize classes isn't working unless the
persistence.xml file is open in the editor. I'm going to enter a bug
for that one, I seem to be able to get it working either when it's in
the editor or when it's not, but I can't make both work yet :)
thanks,
Karen
Tom Mutdosch wrote:
Hi Karen,
Along the same lines of setting the updater back... it looks like
setting a SynchronousUpdater really causes performance to take a hit
in our scenario (we are modifying a number of different Java files
using the JDT models, etc) so I don't think we would want to use the
SynchronousUpdater during the entirety of our wizard operation. Is
there any problem with just setting a SynchronousUpdater during the
times that it's needed (as is the case when we need to wait until the
entities have been generated) but then setting it back to Asynchronous
after that point when we do not need to wait for Dali model updates
after that? I'm not sure if this would cause problems (for example if
I set the updater back to Asynchronous but it was in the middle of a
synchronous update or something).
-Tom
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