David,
I agree, probably not worth the abstraction. With the possibility of
extending our connection support in the future, any extra configuration
detail will also probably mean "just one more legacy artifact" to work
around. Simpler is almost assuredly better.
For deployment, the details are all still specified in the JPA-specific
files, such as persistence.xml. The DTP connection is a design-time
artifact that we have to introduce so that developers can use a
different connection from the deployment data source.
- Paul
David M Williams wrote:
I suggest "2" as well, since
"sharing" database connections, even by name, doesn't seem
that realistic (as you note, even to
test one database versus another) and in my experience,
every developer has their own
databases,
and "special cases" they are interested in
developing against.
I would wonder, though ... if you
could
abstract a little further, and have a symbolic name
defined in the project-specific
settings,
with a default of "JPADatabaseConnection" :)
and then each developer have a
project
specific workspace setting to associate the
symbolic name with the "real"
database connection name?
It may not be worth that
abstraction,
but just seemed an obvious way to have the best
of both worlds.
Plus, I don't know enough of the
domain,
but how does this choice effect deployment?
Is one (still) a fixed database
name,
and the other is any 'ol database connection?
Or does it not matter at deployment?
Thanks,
Hello all,
We had some discussions in our daily dev meeting about where to store
various project settings. Currently we have two such settings: JPA
platform and DTP connection. Since the JPA platform is such an
important part of the definition of a project, similar to a facet, we
decided that it should be stored as part of the project's resources in
the .settings folder, similar to how facets are stored. But the DTP
connection is a bit different. There are three standard places that
information can be stored in eclipse: as a workspace-wide preference,
as
a project-specific workspace preference, or as a project-specific
setting (as we decided to store the JPA platform). We'll be storing
a
reference (a String) to a DTP connection, which is defined and stored
by
DTP plugins in the workspace-wide preferences. It makes sense to
store
DTP connections that way, since they're not really associated with any
project in particular, but since our reference is most definitely
project-specific, we ruled out the workspace-wide preference route. We
are still somewhat in doubt about whether to store this information as
a
project-specific setting or a project-specific workspace preference.
The two methods are outlined below.
1) Project-specific setting: Information stored in this method are
shared among team members (that is, they are part of the project's
resources). WTP facets and JDT-specific settings are commonly stored
here. Storing our reference string here would signal to users that
they
should set up a DTP connection by a certain name. (for example,
"TestPetStoreDataSource") It would also mean that in order
to change
the connection (such as for test-validating against a deployment data
source) a user would have to edit the actual DTP connection instead of
switching to a different DTP connection (that is, if they didn't want
to
be out of synch with the shared project.)
2) Project-specific workspace preference: Information stored in this
method is not shared among team members. It exists for one project
in
one workspace. This mechanism is most commonly used for storing
overridden workspace preferences, such as those for java coding style
or
WTP validators, but it is also the primary mechanism for storing such
things as the cvs repository for a project. If we stored our
connection
reference string here, it would allow users to specify their own DTP
connection names. They would still get a problem prompting them to
set
up a connection for a JPA project, but wouldn't get a naming clue about
what the connection should be. However, they'd be able to switch
between DTP connections (or use existing ones) without having to edit
the information within the DTP connections themselves.
I think we're generally leaning in the direction of #2, but we wanted
to
get some community feedback on this.
--
Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development
paul.fullbright@xxxxxxxxxx
_______________________________________________
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
--
Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development
paul.fullbright@xxxxxxxxxx
|
