Tom,
Given that this is a maintenance release we are talking about, you
certainly had every right to be concerned. Unfortunately we didn't
foresee the compatibility issues that might arise here, so that was our
mistake.
My original thinking is that we would want to revert this change, as
breaking adopters in a maintenance release is not an acceptable thing
to do under most circumstances. Given that you have been able to
adjust to the change, that we have not heard any other concerns about
this, and that the change has great benefit to the user, we will leave
it in for 1.0.1 unless there are other objections.
Thanks for working with us on this.
Neil
Tom Mutdosch wrote:
Hi Karen,
I understand why the change was made, and I agree that it is definitely
a good improvement. I may have come off a bit "the sky is falling!",
but I think the issue primarily was just that it was done on a bit of
short notice (from our side anyway) and we were not expecting it. It's
always difficult to know which code adopters are using, and how they
are using it, so I realize it was probably hard to tell that the fix
would change anything functionally. I personally don't mind minor
potentially breaking changes that provide a gain, as long as there is a
bit of fair warning and an easy migration path.
With that said, we have reacted to the change using the Job approach
that you first suggested (scheduling our operation in a Job that runs
on the same Project which is guaranteed to run after your Job). This
seems to work okay for now, so I am fine with keeping the change in the
maintenance release, since I agree that the improvements that it
provides are valuable.
For 2.0, if we could change this over to something more of an API like
you mention, that will be great (since the current Job approach is
hacky and error-prone). Thanks for all the explanations and
suggestions.
Tom
dali-dev-request@xxxxxxxxxxx
wrote:
Message: 1
Date: Fri, 7 Sep 2007 11:53:56 -0500 (CDT)
From: Karen BUTZKE <KAREN.MOORE@xxxxxxxxxx>
Subject: Re: [dali-dev] Listening for Entity Generation operations
To: "General Dali EJB ORM developer discussion."
<dali-dev@xxxxxxxxxxx>
Message-ID:
<27263723.1189184036480.JavaMail.oracle@xxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain;charset=US-ASCII
Tom,
I agree that we probably should have waited until 2.0 to make this change because it has broken adopters. We made the change for two reasons: 1. to add the progress monitor since the end user experience was a locked up UI with no status or progress shown. 2. bug 183279 involved a concurrent modification exception because the persistence.xml synchronize classes was happening at the same time that we received updates from the JDT for the newly created classes.
At this point, there are two options. We can revert back, lock up the UI and have no progress monitor, in an effort to not break adopters in a maintenance release. I do now have a solution to 183279 without the other changes. The second option is to go ahead with the changes since it really helps end users to have the progress monitor and since we would like to make these changes in the 2.0 release anyway. Which would you (spokesperson for the community) prefer?
I think your solution sounds reasonable. In the Dali UI it makes sense to have the Job run in the background so that the UI is not locked up. In your code, since you are going to open a dialog showing all the generated entities, it probably makes sense to run on the UI thread and lock. The biggest problem I have with that solution is I can't figure out a way to have anything other than a NullProgressMonitor without using the Job.schedule() method. Am I missing something obvious? If you know of a solution that might be another option for 1.0.1.
Sorry for all the turmoil in a maintenance release, I got excited that I could fix the progress monitor issue and didn't realize what it would do to adopters :)
thanks,
Karen
-----Original Message-----
>From Tom Mutdosch <tommut@xxxxxxxxx>
Sent Fri 9/7/2007 10:25 AM
To dali-dev@xxxxxxxxxxx
Subject Re: [dali-dev] Listening for Entity Generation operations
Hi Karen,
We could probably copy a bunch of code, but this seems like a big
reaction to a change for a Dali maintenance release, and is going to
cause us to rewrite a bunch of our code. I think this change may have
actually been spurred by one of our bug reports requesting an
IProgressMonitor to be added to the EntityGeneration operation, but I'd
rather have had this change deferred to the 2.0 release since it is a
behavioral change of some significance.
In any case, what we really want to do is basically in a black box have
the user launch the Dali wizard and generate entities and then we want
to display those generated entities. We really don't need to do any
specialized wizard or entity generation, so the API you mentioned would
probably be more than what we need in our case. Really, we just need
some sort of event notification that the entity generation is finished
which we could listen for. This is why we had requested the ability to
pass in our own ProgressMonitor. I imagine the Dali model is listening
for new entities being created. Is some way we could listen for these
changes as well to update our display?
I think for now as you mentioned it might be easiest if we just
overwrite some of the Dali code. We currently are just calling
GenerateEntitesAction.execute(). Instead, it sounds like we could call:
new EntitiesGenerator( project, selection).generate()
and overwrite the generate() method to call
WorkspaceJob.runInWorkspace(IProgressMonitor) instead of
WorkspaceJob.schedule(). I think that would give us exactly what we
are looking for; it would allow us to run the operations in the
foreground (as it used to) and allow us to pass our own progress monitor
that we could then listen on. Does this sound like it should work for
what we need for the present?
Thanks
Tom
Message: 2
Date: Wed, 05 Sep 2007 12:57:01 -0400
From: Karen Moore <karen.moore@xxxxxxxxxx>
Subject: Re: [dali-dev] Listening for Entity Generation operations
To: "General Dali EJB ORM developer discussion."
<dali-dev@xxxxxxxxxxx>
Message-ID: <46DEDFDD.4000305@xxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Tom,
It seems that what you (and probably Chris as well) really want to do is
to run the wizard and the entity generation operation yourself. In the
generic platform we call
org.eclipse.jpt.ui.internal.generic.EntitiesGenerator.generate(IJpaProject,
IStructuredSelection). In here we run the GenerateEntitiesWizard and
then schedule the WorkspaceJob that generates the entities and
synchronizes the persistence.xml classes. You should probably be using
PackageGenerator.generateEntities() which takes an IProgressMonitor. I
would assume that you would copy a lot of the code in EntitiesGenerator
and change how the Job is run. Then you would be able to hook in at the
right moment to do your post-processing, probably before the
persistence.xml SynchronizeClassesJob is run. Look at the code in
EntitiesGenerator.GenerateEntitiesRunnable.runInWorkspace(IProgressMonitor).
I would expect your code to come after the call to
PackageGenerator.generatesEntities().
The most likely candidate for public API here is
PackageGenerator.generateEntities(Config, EntityGenerator.Config,
Collection<Table>, OverwriteConfirmer, IProgressMonitor). Does this
sound reasonable?
Karen
_______________________________________________
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
End of dali-dev Digest, Vol 24, Issue 5
***************************************
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
|
