Hi Ariel, >> Care to submit an issue for this. > > Component and subcomponent? (maybe stupid question, but sometimes I've > no idea where to submit)
Database Access. There is only one sub component "none" :) (we got rid of all others because they don't had any real value in our issue handling) >> Actually, it seems the value of the "Name" node is nowhere used, >> except in the database registration dialog. You even cannot use it in >> the database context's getByName (which is different to what you write >> in your .xcu) > > ups! I wrote it ... but didn't test :-[ > It seemed to me obvious that it should work... so what? getByName() must > use the node's logical name? I'd say so, yes. One could think of allowing the display name to be accepted, too, but the default should be the programmatic name. The reasoning is that the display name could (potentially) be localized - for instance there is no real reason why in every language's installation of OOo, the bibliography is always named "Bibliography", people rightfully expect to read a name in their language. If this would be the case, then the code which accesses a certain DB (say the mail merge wizard which currently hides the bibliography DB from the user) must be able to use the programmatic name, not the localized one. > [renaming data sources in from the extension config layer] > BUT you're right: if the user changes the name everything gets erased! That's what surprised me, too. > <node > oor:name="ar.com.arielconstenlahaile.ooo.demo.dbaccess.SampleDatabase1" > oor:op="remove"/> > <node > oor:name="ar.com.arielconstenlahaile.ooo.demo.dbaccess.SampleDatabase2" > oor:op="remove"/> That's the confusing part .... > </node> > ************************************************************************* > > * As you see the TWO DBs get removed: but I changed only one. Is this an > issue? ... which I would consider an issue. I am not sure whether this is the data source registration dialog doing this nonsense, or the underlying configuration. Might be the former, so you might want to start with component "Database Access". > * the config. manager uses for the logical node name and the "Name" node > the same name. Is this an issue too? That's done by the data source registration dialog, I suppose. As long as the "Name" property of a node is not really used, I think that's not an issue. When it gets used, I expected renamings to not touch the logical name of the node. > The EXTENSION layer does not change Configuration data is layered, with the content of share/registry being the "lowest" layer, and "user/registry" being the hights. Obviously the user extensions's config layer is between those both, as is (supposedly) the shared extension's config layer, if you have installed one. Write access is always done to the top (user) lay, with hiding everything in the lower layers. Thus, whatever you do in the UI, will be reflected in the user layer only. > But changing ALL the extension DataAccess config. in the user's side > when he only changes ONE, does not seem so logical. Agreed. As said, it's possible this is a bug in the data source registration dialog. > ... hmmm ... sounds issue-like ... for example I never could make any > kind of constraint work in the configuration Really? I know some time ago, we implemented features that certain options could be locked, IIRC by adding the "finalized" attribute. In this course, the respective UI was fixed to respect the "read-only" state of the configuration it works with. At least, there was a list of settings for which this "UI respect" was implemented. So, in my opinion there *is* a way how to lock config settings, and in the core it should work for *all* settings, only UI is usually not prepared for this. However, detailing this would be better done in, hmm, [EMAIL PROTECTED], I'd suppose. >> - Trying to connect to the sample DBs in the DSB (or after opening >> them from within the DSB) gives some "Invalid argument in JDBC call" >> error. Huh? Might be related to the naming issue from the first item, >> because connecting is possible when the DB is opened from your sample >> menu. > > I tried to reproduce it here on Linux SuSe but couldn't > I renamed a registered one (the only that has a table) and both DBs > worked on the DSB... but NOT in the menu any more: as you said, the > config. gets deleted! [I was prudent and used conditional blocks so no > crash takes place] > >> Care to submit another issue "Cannot connect to database shipped >> with extension"? > > Can you detail what you've done so I try to reproduce it here? > And may someone in the list can also give a try Straight forward: Install your extension, open the DSB in Writer, expand the node of one of the two new data sources, expand the tables node => got the mentioned error. >> Other than that: cool stuff (and yes, the non-cool stuff is on OOo side :(). > > Well... seems like the "Sample Extension" was too buggy... at least, > getting a localized ODB worked ;-) Seems it wasn't the extension, but OOo. > I tend to think that nobody had even try to do this (registering a data > source in an extension), and it has never been tested by QA Most probably, yes. > Nevertheless, this could/should have been included in > http://wiki.services.openoffice.org/wiki/Non-code_extensions > although this wiki is mainly about Paths.xcs/xcu, using > DataAccess.xcs/xcu is also a "Non-code_extensions" Feel free to add it, I'd say :) > Final conclusion: though my personal opinion is to use add-on config. > and not DataAccess config., I can think about several valid scenarios > where an extension may want to use DataAccess; and technically, it > should work :-( Agreed. > I will give it a deeper test to find issues! Thanks. Looking forward to see them materialize in IssueZilla. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
