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.
Proposal: Add a setter/getter for an "advanced property" to DatabaseConnection. Replace DatabaseRuntime.acceptsDatabaseURL(String) with DatabaseRuntime.managesRuntimeStatus(DatabaseConnection). 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.
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.
As noted in issue 62758, needs API review. If possible will try to fix in 5.0.
Response to Sep 30 comments: 1. No setter... okay, it is your api 2. owner sounds okay, I guess. 3. okay
Created attachment 26795 [details] javadoc for proposed change
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.
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?)
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 calculated.... 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.
Ludo: 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?
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! DIGRESSION--- 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)... ---NOISSERGID 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)
Vince: Re. arch document update: according to http://openide.netbeans.org/tutorial/review-steps.html 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.
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?
Vince, any comments to my last post yet?
TM 5.0 -> TBD
Will this get addressed in 7.0? Please...
Reassigned to new owner.