Re: [dali-dev] Storing connection information

[Tom Mutdosch <tommut@xxxxxxxxxxx>]

Hi Paul,

I think I might lean towards method #1.  I think it can be fairly common 
when creating connections to default to the database name (which is the 
current behavior in WTP) -- for example "SAMPLE" or "SAMPLE_con".  So 
given that, in a team environment each member could likely have the same 
DTP connections created in each of their individual workspaces.  So if 
the connection name was stored as a project-specific artifact, bringing 
the project into the workspace *could* "just work", with no other 
setup.  Whereas in method #2, this could never happen. 

Another benefit is that all projects could point to the same connection 
name which would only have to be defined once (the DTP connection).  It 
is common for our product test teams to have dozens of various projects 
to test varying functions, and many of these projects utilize the same 
connection.  In method #1 they could import all the projects and at most 
they only need to create/modify a single target DTP connection.  In 
method #2, they would have to go to every single project and set the 
project property on each, which seems like a lot of work (unless I'm not 
getting how that would work).   

Those are my reasons behind liking method #1; it seems more beneficial 
in practice.

Regards,
Tom


Paul Fullbright wrote:
>
>     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.
>