Re: [dali-dev] Re: help with Dali 2.0 model migration - how do I now get

[Karen Moore <karen.moore@xxxxxxxxxx>]

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