This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 65426 - api changes for better runtime management
Summary: api changes for better runtime management
Status: NEW
Alias: None
Product: db
Classification: Unclassified
Component: Code (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Libor Fischmeistr
Keywords: API
Depends on:
Blocks: 62758
  Show dependency tree
Reported: 2005-09-29 20:16 UTC by Vince Kraemer
Modified: 2013-08-01 12:51 UTC (History)
1 user (show)

See Also:
Exception Reporter:

javadoc for proposed change (102.95 KB, application/x-compressed)
2005-11-09 18:37 UTC, Vince Kraemer

Note You need to log in before you can comment on or make changes to this bug.
Description Vince Kraemer 2005-09-29 20:16:35 UTC
Add a setter/getter for an "advanced property" to DatabaseConnection. 
Replace DatabaseRuntime.acceptsDatabaseURL(String) with

Use case:

Many app servers come with a DB preinstalled (like SJSAS 8.1 and Pointbase).
A plugin for the app server may want to register the database connections that
it "knows about". The SJSAS 8.1 plugin currently does this....

Currently, a plugin has no way of being certain that a database connection is
one that it manages, since any number of runtimes may register the same db
url... this is currently the case for weblogic and sjsas 8.1.  There is also
nothing PREVENTING this situation from becoming worse in the future.
Comment 1 Andrei Badea 2005-09-30 10:30:55 UTC
Seems like a good idea and it could be done. Incompatible API change though, and
I also have a few comments:

1. No setters. DatabaseConnection is read-only for its clients. I will create a
new constructor accepting a parameter for the new property.

2. Could you propose a name for the new property? What about "owner" of type String?

3. The same property should be added to the database connection DTD.
Comment 2 Andrei Badea 2005-10-13 17:48:13 UTC
As noted in issue 62758, needs API review. If possible will try to fix in 5.0.
Comment 3 Vince Kraemer 2005-10-18 19:54:02 UTC
Response to Sep 30 comments:

1. No setter... okay, it is your api
2. owner sounds okay, I guess.
3. okay
Comment 4 Vince Kraemer 2005-11-09 18:37:57 UTC
Created attachment 26795 [details]
javadoc for proposed change
Comment 5 Vince Kraemer 2005-11-09 18:43:50 UTC
I have attached javadoc for the proposed change.

I have rolled in the request for a client defined display name and changes that
would allow a single Runtime to manage multiple processes...

Note: a runtime doesn't have to support multiple processes.  Right now a runtime
CAN NOT support multiple process.  The combination of this fact and the fact
that I could not find a way to register MULTIPLE DatabaseRuntime objects
dynamically limits the functionality of the DatabaseRuntime.
Comment 6 _ ludo 2005-11-09 19:00:56 UTC
I guess the jdbc driver DTD has to be updated with the new fields?
Same for the example in the use cases section.

What is the display name or ownerdata is the fisrt create method is used?
The order of params might be better" display name first, then ownerdata.

Not sure if we need a setOwnerData() to update some info after a create...
Is there a rule for duplicated display name?
In the UI, what is the ordering used: alphabetical?
In the UI, is there a way to see the extra info (tool tip, property?)
Comment 7 Vince Kraemer 2005-11-09 19:31:54 UTC
Response to ludo [Nov 9 19:00:56]

DTD update? Yes. I guess that would be necessary.  Since I am a client for this
I don't know all the impl details that this change involves.

Old create and new property (ownerName) and display name: ownerName would be
null, display name would use the current value.  I don't know how it is

paramater order: good point. since multiple folks will have an opinion on this I
am going to wait for some consensus before I change it up though...

setOwnerData : already overruled by abadea see [Sep 30 09:30:55]

Display name issue in UI: don't know. good question for a UI review. (I don't
know if the db explorer can handle duplicate display names. There may be a bug
in the connection manager that would prevent this from working well)
Displaying the extra info: don't know. good question for a UI review.
Comment 8 Andrei Badea 2005-11-09 20:32:25 UTC

Re. DTD update: yes. Not the driver, but the connection DTD. I will do it and
update the arch document.

Re. ownerData and displayName values if not specified: null for ownerData, null
for displayName (but in the UI we should display what we display now, that is
the connection name).

Re. parameter order: agreed. I would even provide a constructor with the
parameters of the current one and displayName.

Re. setOwnerData(): I wouldn't add it unless there is a use case for it. No
problem to add it later (compatible API change).

Re. duplicate displayName. You can technically have multiple connections with
the same displayName. Note however that you can't have two connections with the
same name (by name I mean what we currently display in the UI, returned by the
DatabaseConnection.getName() method). No strong opinion. I suggest we display
the connection name in the node tooltip, that would help with the duplicates. 

Re. displaying the "extra info". I guess you mean ownerData. I wouldn't display
it in the UI, I don't see a reason for it.

I also just realized that if an user manually creates a new Pointbase database
along the sample ones and adds it to the UI, the server won't be started when
connecting to it, because it won't have the ownerData parameter set. Do you
consider this a problem?
Comment 9 Vince Kraemer 2005-11-09 22:38:13 UTC
Added pjiricka to the CC list. He might be interested in this.

Response to  abadea [Nov 9 20:32:25]

DTD and arch document: are we "ready" to present this to a real review? 
Changing these docs at this point seems premature.

null return for display name: is that the way display name works now?  I thought
display name was returning the URL (value of arg 2 when create(...) was invoked.
Changing this to return null may be a big bite to chew.

Sounds like we probably need four create methods... What We Have Now,
WWHN+ownerData, displayName+WWHN+ownerData, displayName+WWHN....  The order is
significant since doing WWHN+ownerData and WWHN+displayName is ambiguous....
unless ownerData becomes something other than a String!

Dealing with dups: This is really going to get sticky...  Say I register two
instances of an app server (like GF and 8.2) that BOTH have sample databases at
the same "name"/URL...  If the current impl of ConnectionManager and stuff
headed towards the user cannot handle this we will get issues filed.  Does the
ConnectionManager do something nice to say tell its client that addConnection is
being ignored (or worse)...

User doesn't get the magic (auto-start on connect) : The user is currently out
of luck on this anyway.  And worse... The user may not understand why trying to
connect to DB connection A starts a a totally different database. That is what
62758 is all about! Even worse still.... say the user has a DB created with
version X of database engine Y "already". They load a DatabaseRuntime that knows
how to start version Z of Y.  If version Z of the engine "upgrades" data from
version Y, the users data might actually be CORRUPTED...

Note: GF knows how to do this upgrade.  It does it when you start an 8.1 domain
using the 9.0 engine... (so this isn't super-hypthetical)
Comment 10 Andrei Badea 2005-11-10 21:25:53 UTC

Re. arch document update: according to the arch document should
be updated for the review

Re. null and getDisplayName(): returning null is a nonsense, of course. Sorry,
must have been really tired last night. So  getDisplayName() either returns
displayName if one was passed to DC.create(), or it returns the same thing as
getName(). Currently it returns the same as getName(), so we don't break anything.

Re. the create() methods: only add those that we have a use case for. Suggest
dropping WWHN + ownerData, as we should always pass a displayName.

Re. digression: I understand both GF and appserver 8.2 will use Derby. If so,
then this is not an issue, since for Derby the databaseURL will contain the
absolute path of the sample database (see an e-mail I sent about two days ago to
cdp-j2ee-dev). Thus there will not be two Derby sample databases with the same URL.

Re. the magic: currently if an user creates a new Pointbase database in the
directory where the sample databases are, the Pointbase server will be started
for this database. This will cease to function when ownerData stuff is
implemented. You're right about starting a completely different db under certain
circumstances, of course.

Re. data upgrade: so what exactly happens when you start a 8.1 domain containing
a Pointbase database with the 9.0 engine? I thought 9.0 wouldn't bundle Pointbase.
Comment 11 Andrei Badea 2005-11-10 21:37:30 UTC
Just got the follwing idea. Give the DatabaseRuntime a name (for identifying it)
and a displayName (for displaying it in the UI). Instead of "ownerData" have a
"databaseRuntime" property identifying the DatabaseRuntime which should be used
to start the DatabaseConnection. When the DatabaseConnection is connected find
the DatabaseRuntime specified by the databaseRuntime property and try to start it. 

The advantage of this approach is:

- we get the same thing that ownerData did

- we get the possibility to show the DatabaseRuntime's in the UI and let the
user choose one. 

I don't think we should show the database runtimes in the UI in 5.0. It could be
useful for Pointbase, but then again only for Pointbase. Howerver, if the need
arises to do so in a future version, we'd be ready.

What do you think?
Comment 12 Andrei Badea 2005-11-19 16:18:25 UTC
Vince, any comments to my last post yet?
Comment 13 Petr Blaha 2006-03-13 13:32:09 UTC
TM 5.0 -> TBD
Comment 14 Vince Kraemer 2007-12-08 03:46:58 UTC
Will this get addressed in 7.0? Please...
Comment 15 Jiri Rechtacek 2009-10-16 14:04:57 UTC
Reassigned to new owner.