Hi Tom,
Tom Mutdosch wrote:
Hi
guys,
Regarding Dali 2.0, hare are two areas that I wouldn't mind seeing.
1) Handle populating persistence.xml with connection info (maybe this
was already in plan).
This wouldn't apply if you wanted to use a datasource and if you did
want to use an actual connection the properties would be JPA provider
specific. I like the idea myself and it has been discussed but it
would have to either be part of the platform functionality or bundled
with it.
a) It seems redundant that I create a connection when I add the JPA
facet and generate my entities, and then I need to put all of those
same connection properties into my persistence.xml, and the tools
already know what needs to go in there. I realize that this is
provider-specific, so it probably has to tie in there.
You're right, it is provider specific but there's also the issue of
design time vs. run/deployment time connection information. Myself I'm
in favor of it but it's probably a platform extension.
b) if using a datasource, it would be nice if there was some way to add
that (either from the wizard, or an editor).
2) Allow developers and providers to better extend Dali's and utilize
capabilities.
a) I would like to extend/override some of Dali's entity generation.
Bug 186288 mentions that I can provide my own Generation wizard, which
is really not what I would want to do. I just want to do some simple
things such as choose how temporal types are generated (for example,
java.util.Date vs. java.sql.Date as I mentioned previously). I'd
rather not have to do a whole bunch of extending internal Dali wizards
just to get some small improvements (or worse as I'm doing now, and
running a post-operation to go through all the generated entities and
load up the Dali models to add annotations to the entities, etc).
I agree we need more flexible Entity generation. What I'd like to see
here is a contribution from one of our adopters (you know you you are
:-). There's plenty of work to do on Dali 2.0 and more contributions,
especially areas that are reasonably isolated would be appreciated.
I'm aware of at least three large companies either planning to or in
the process of building on or bundling Dali. It would be great to get
some code contributions from the adopter community.
b) open up the Dali models and make them usable from outside of the JPA
properties view. Dali has some really nice models which are currently
all marked internal. It would be nice to open these up and make it
easy to update them. Currently this is difficult in that they seem
somewhat tied to the property view and it's not easy to run these
operations outside of the UI thread. Each model update needs to be
wrapped in a Display.syncExec (bug 184479), and some model updates are
slow as they send a lot of notifications (bug 191122) even if called
headlessly from outside the properties view. And currently, I need to
get the compilation unit after each model update and save it myself.
If I'm dealing with the Dali model, ideally I wouldn't have to know
about or interact with compilation units.
Model enhancements and public API are definitely something that will be
on the 2.0 roadmap. What we need to do is to identify what that public
API should be. This is an area adopters and extenders need to be
vocal about because they are the ones who will use this API. In other
words, you're on the right track. Bug reports/enhancement requests
with use cases and identification of necessary or missing public API
would be great!
Shaun
The Dali 1.0 release is fantastic, and I look forward to 2.0. Thanks
for all the good work, guys.
-Tom
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
--
Shaun Smith | Principal Product Manager | +1.905.502.3094
Oracle TopLink
110 Matheson Boulevard West, Suite 100
Mississauga, Ontario, Canada L5R 3P4
|
