Skip to main content
[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,
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

Back to the top