Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Michael, > Okay, I went through some documents introducing to the CWS concept. In > case using a CWS to apply my changes, I'll need to checkout the most > recent milestone via cwsquery, create the CWS via cwscreate, apply my > changes locally to the CWS and commit them to the CWS via a CVS commit, right so far. If you want us to, we can create the CWS for you - that's a service for first-time contributors ;) to relieve them from some stuff. > but I'll need to get an CWS account, right? How do I get the account? For committing, you definitely need a SSH key submitted to us. Since we just migrated to Subversion, I refer you to http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#SSH_Setup here, which describes how to create and submit your SSH key. When you submit an issue where you attached the SSH key, put me (fs) on CC, so I can approve your request for commit access. Finally, enter your data on http://wiki.services.openoffice.org/wiki/DomainDeveloper, as appropriate (name and OOo login name, IRC nick and company if applicable/desired). Note that since the migration from CVS to SVN realy just happened yesterday, I expect problems on the way - personally, I did not yet work on a SVN-CWS, probably some tooling might not yet be as polished as desired, and so on. So, I beg for your patience when working with this ... 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]
RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 30. September 2008 13:29 > To: dev@dba.openoffice.org Hi Frank, > If you want, we can create a CWS based on this milestone, and commit > your changes (or you can do yourself, if you want, after we granted > you permissions to do so). Any adjustments which are possibly needed > can then happen in this CWS, and we can fine-tune it without > disturbing other development. > > Such a dedicated CWS would be easier (than a patch in IZ) in case you > expect more changes to the first patch version, but has more overhead > in case your first patch is perfect :) Okay, I went through some documents introducing to the CWS concept. In case using a CWS to apply my changes, I'll need to checkout the most recent milestone via cwsquery, create the CWS via cwscreate, apply my changes locally to the CWS and commit them to the CWS via a CVS commit, but I'll need to get an CWS account, right? How do I get the account? Possibly the driver needs some more adoptions then I thought at first, so doing the integration the CWS way is probably preferable. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Michael, > It's been a while since I wrote to the mailing list last time, because I > was on vacation. You may remember that we were working on a driver. We > are finished with the driver so far and would like to integrate it into > the core code base. Probably we need to do some small changes to code to > integrate it in base's connection dialog and some more stuff. What is > the current OOo built which should be used as foundation for this? I > will submit an issue with type enhancement or feature with code patches > if this is what you need for integration into the core code base. DEV300 m31 is the most recent milestone (m32 is the first SVN-based milestone, not sure when it will finally be released). If you want, we can create a CWS based on this milestone, and commit your changes (or you can do yourself, if you want, after we granted you permissions to do so). Any adjustments which are possibly needed can then happen in this CWS, and we can fine-tune it without disturbing other development. Such a dedicated CWS would be easier (than a patch in IZ) in case you expect more changes to the first patch version, but has more overhead in case your first patch is perfect :) Your decision. 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]
RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hello Frank and Ocke, It's been a while since I wrote to the mailing list last time, because I was on vacation. You may remember that we were working on a driver. We are finished with the driver so far and would like to integrate it into the core code base. Probably we need to do some small changes to code to integrate it in base's connection dialog and some more stuff. What is the current OOo built which should be used as foundation for this? I will submit an issue with type enhancement or feature with code patches if this is what you need for integration into the core code base. > Submit an issue in IssueZilla, attach your changes. They'll be > reviewed, possibly you'll be asked to do some changes, and then we'll > take care of integrating it. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Micha, Michael Strobel wrote: Hi Ocke, I'm back :-) That's great news, at least me ;-) Hope you had a good vacation. Yes, Indeed I became a father. So less sleep. :-) First of all I have to clarify that default values which you enter in the table design window are never propagated to the driver. These default values are only UI values which will be shown when you open the table to add data. What may me confuse is the fact that your alter command is called. Normally I would argue that some props of the column type has changed. May be the problem is databasemetadata::getColumns for that table (type nfo of the column), but that is only a guess. What could be the problem with properties of the column type exactly? If it is because of a difference between the result of getTypeInfo() and getColumns() this is likely a fault in our JDBC driver, which explains why the problem does not appear with MySQL and the SDBC-JDBC bridge, but as far as I could see the problem is independent of the column type. I'll check that and the results of the both methods. I only thought that this could be the problem of the alter statement. The table design checks if any changes happen. The best place to look at is :DoSave in TableController.cxx in dbacces or alterColumns. - oj Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Nagelsweg 55 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke, > I'm back :-) That's great news, at least me ;-) Hope you had a good vacation. > First of all I have to clarify that default values which you enter > in the table design window are never propagated to the driver. > These default values are only UI values which will be shown when > you open the table to add data. > What may me confuse is the fact that your alter command is called. > Normally I would argue that some props of the column type has > changed. May be the problem is databasemetadata::getColumns for > that table (type nfo of the column), but that is only a guess. What could be the problem with properties of the column type exactly? If it is because of a difference between the result of getTypeInfo() and getColumns() this is likely a fault in our JDBC driver, which explains why the problem does not appear with MySQL and the SDBC-JDBC bridge, but as far as I could see the problem is independent of the column type. I'll check that and the results of the both methods. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Moin Micha, Michael Strobel wrote: Hi Frank, The table designer is in dbaccess/source/ui/tabledesign. Saving a changed design is centrally done in OTableController::alterColumns - this is where I would start. For the various column classes involved ... I'm not sure which of the ones in dbaccess/source/core/api would be the best to start with (Ocke would be able to answer this more precise, but he's still on vacation), I'm back :-) I suggest you simply touch every file with "column" in its name, and every file which a "grep DEFAULT *" mentiones, build them with "debug=1", and let the debugger guide you, starting from the aforementioned alterColumns method. I managed to compile the dbaccess module with debug information, but I'm still stuck with the bug because I do not really understand the code in dbaccess and what's going on in there. Do you know when Ocke will be back from vacation? Maybe he might have a clue as you said. Looks like OColumnSettings in dbaccess/source/core/api/column.cxx is used to work with the column specific information that is stored in the base document, while m_aControlDefault holds the default value and OTableController in dbaccess/source/ui/tabledesign/TableControler.cxx has alterColumns(), which is called when you hit the save button in Base's table designer for altering the column specific information. I also need to say that the problem appears only when altering a column default, but not when I add a new column with a default to an existing table. First of all I have to clarify that default values which you enter in the table design window are never propagated to the driver. These default values are only UI values which will be shown when you open the table to add data. What may me confuse is the fact that your alter command is called.Normally I would argue that some props of the column type has changed. May be the problem is databasemetadata:.getColumns for that table (type nfo of the column), but that is only a guess. Best regards, Ocke Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Nagelsweg 55 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Frank, > The table designer is in dbaccess/source/ui/tabledesign. Saving a > changed design is centrally done in OTableController::alterColumns - > this is where I would start. > > For the various column classes involved ... I'm not sure which of the > ones in dbaccess/source/core/api would be the best to start with (Ocke > would be able to answer this more precise, but he's still on vacation), > I suggest you simply touch every file with "column" in its name, and > every file which a "grep DEFAULT *" mentiones, build them with > "debug=1", and let the debugger guide you, starting from the > aforementioned alterColumns method. I managed to compile the dbaccess module with debug information, but I'm still stuck with the bug because I do not really understand the code in dbaccess and what's going on in there. Do you know when Ocke will be back from vacation? Maybe he might have a clue as you said. Looks like OColumnSettings in dbaccess/source/core/api/column.cxx is used to work with the column specific information that is stored in the base document, while m_aControlDefault holds the default value and OTableController in dbaccess/source/ui/tabledesign/TableControler.cxx has alterColumns(), which is called when you hit the save button in Base's table designer for altering the column specific information. I also need to say that the problem appears only when altering a column default, but not when I add a new column with a default to an existing table. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Frank, > Hmm - you couldn't reproduce the default values vanishing, or you > couldn't reproduce the default values not being passed to the driver? I couldn't reproduce the vanishing. The defaults were saved correctly when connecting via the SDBC-JDBC bridge to MySQL or via OOo's MySQL driver. However, when connecting to Ingres via the SDBC-JDBC bridge or using my driver the vanishing appears. Playing around with the drivers a bit more I also recognized folloing: When changing default values and using OOo/MySQL the method OMySQLTable::alterColumnByName is not even called, which makes sense as this doesn't require to execute anything on the database, but when using OOo/Ingres OIngresTable::alterColumnByName is called. > Sounds a little bit like there lingers another bug somewhere ... > > The table designer is in dbaccess/source/ui/tabledesign. Saving a > changed design is centrally done in OTableController::alterColumns - > this is where I would start. > > For the various column classes involved ... I'm not sure which of the > ones in dbaccess/source/core/api would be the best to start with (Ocke > would be able to answer this more precise, but he's still on > vacation), > I suggest you simply touch every file with "column" in its name, and > every file which a "grep DEFAULT *" mentiones, build them with > "debug=1", and let the debugger guide you, starting from the > aforementioned alterColumns method. Thanks for this. I will try get further from there. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Michael Strobel wrote: > There is no issue for this, because I wanted to get sure that this is > problem is not related to our driver. Since I couldn't reproduce the > behavior with MySQL today, but only with Ingres I'm not quite sure about > that. On the one hand the default values are not saved by the driver to > .odb, are they? On the other hand I couldn't reproduce it with MySQL. Hmm - you couldn't reproduce the default values vanishing, or you couldn't reproduce the default values not being passed to the driver? > The exact behavior of OOo/Ingres is like this: > > The default values are saved properly when I create a new table. If I > try to change the default values in an existing table only the default > value of the last column of the table is changed successfully. Moreover > this doesn't seem to be saved to the .odb, as the default values are > reset when the connection is closed and reopened. > > Any suggestions what would be a good start for digging further into > this? Sounds a little bit like there lingers another bug somewhere ... The table designer is in dbaccess/source/ui/tabledesign. Saving a changed design is centrally done in OTableController::alterColumns - this is where I would start. For the various column classes involved ... I'm not sure which of the ones in dbaccess/source/core/api would be the best to start with (Ocke would be able to answer this more precise, but he's still on vacation), I suggest you simply touch every file with "column" in its name, and every file which a "grep DEFAULT *" mentiones, build them with "debug=1", and let the debugger guide you, starting from the aforementioned alterColumns method. 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]
RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Frank > IIRC (it's a while since I last stepped through this code), the > problem is that we the default value entered in the UI is stuck in the > higher layers. We remember it in the ODB file (as part of the column > settings), but we never pass it to the driver. > > Thus, the default value is "lost" before any SQL statements are > generated and sent to the driver. So that's why there is no "default ..." in the trace output. Since no default value is passed to the driver it is never put it into any statement. I could verify that, by looking at the corresponding variables in the driver, which seem to be empty all the time. > I don't remember the exact details, but there was something why a fix > wasn't as easy as just passing the value down to the driver. Would > need some time to investigate the relationship of the various default > values ... Do we already have an issue for this? There is no issue for this, because I wanted to get sure that this is problem is not related to our driver. Since I couldn't reproduce the behavior with MySQL today, but only with Ingres I'm not quite sure about that. On the one hand the default values are not saved by the driver to .odb, are they? On the other hand I couldn't reproduce it with MySQL. The exact behavior of OOo/Ingres is like this: The default values are saved properly when I create a new table. If I try to change the default values in an existing table only the default value of the last column of the table is changed successfully. Moreover this doesn't seem to be saved to the .odb, as the default values are reset when the connection is closed and reopened. Any suggestions what would be a good start for digging further into this? Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Michael, > I'm still confused what is happening to the default values in Base. You > mentioned before that they never appear in the database and are stored > in the base document instead. Seems to be correct, they do never appear > in the database, but how is that done? IIRC (it's a while since I last stepped through this code), the problem is that we the default value entered in the UI is stuck in the higher layers. We remember it in the ODB file (as part of the column settings), but we never pass it to the driver. Thus, the default value is "lost" before any SQL statements are generated and sent to the driver. I don't remember the exact details, but there was something why a fix wasn't as easy as just passing the value down to the driver. Would need some time to investigate the relationship of the various default values ... Do we already have an issue for this? 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]
RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Frank, > small misunderstanding - supplying the default from within the driver > is exactly the item which we don't have an infrastructure for. We can > easily add a setting to database documents, default it so that the > current behavior is unchanged - but then everybody creating an .odb > for your database type, using your driver, needs to (once) change this > setting. That's still better than showing the dialog (in our case). I'm still confused what is happening to the default values in Base. You mentioned before that they never appear in the database and are stored in the base document instead. Seems to be correct, they do never appear in the database, but how is that done? As far as I can see the drivers in the connectivity module all have methods like alterDefaultValue(), dropDefaultValue() in their Table class, which are at least called from alterColumnByName() and execute an respective SQL statements to alter default values. I have tried to implement this in our driver, but when I look at the trace output of our JDBC driver such a statement is never executed and default values are not always changed correctly. Similar with the create table statements, they should contain a string "default ..." but it never appears in the trace output. Do you perform some extra parsing of the statements before they are sent to the 'real' driver, remove the default stuff and save it to the database documents? Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Michael, > A flag saved at the data source / database document and supplying it's > default from within the driver is absolutely sufficient for our needs. > :-) small misunderstanding - supplying the default from within the driver is exactly the item which we don't have an infrastructure for. We can easily add a setting to database documents, default it so that the current behavior is unchanged - but then everybody creating an .odb for your database type, using your driver, needs to (once) change this setting. > Do you intend to change the driver infrastructure of > OOo at the near future nevertheless? No, that's more a plan, which commemorates itself from time to time, exactly when we notice that the current architecture is too inflexible in some respects. > I have compiled our driver according to the software requirements on > http://tools.openoffice.org/dev_docs/build_linux.html#BuildInstructions > on a RHEL4 and tried to install it in OOo 2.4 and 2.4.1 on different > Linux distributions. If I install OOo from the install packages on > www.openoffice.org everything works fine, but if I install it from the > software repositories of the distributions OOo freezes when I try to > connect to a database. Is this expected? Do I need to compile the driver > in a special way to support the OOo builds in the software repositories > of the distributions? Are they doing such big changes to their builds so > that the driver won't work with them? I didn't realize that before. > Would be nice to have only one driver for the x86 Linux platform > independent of the distribution, if possible. Nice, but quite impossible. The Linux distributions can do all kind of change to their build environment which will make your driver fail. The most simple change: They usually use a much more up-to-date compiler than the vanilla OOo builds use, simply because they do not need to care for baseline requirements (Vanilla has a much wider range of target systems, where the distribution's build of OOo just needs to run on this distribution). One more reason for including the driver in the core code - in this case, everybody building an OOo with own build environment will automatically also build your driver properly. 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]
Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hello Michael, > I didn't do any changes at Base's code base outside the driver so far, > but nevertheless we would definitely like to contribute the driver back > to the core code base :-) Fine, that's welcome > Most of the driver's functionality work's > fine, we are still doing a lot of quality assurance, but possibly there > is a chance to get the driver into the next release. Can you tell me > what the usual procedure when contributing something back to the core > code base is? submit an issue in IssueZilla, attach your changes. They'll be reviewed, possibly you'll be asked to do some changes, and then we'll take care of integrating it. 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]
RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Frank, Nearly forgot that: > If the problem would only be the missing warning, I'd vote for adding > it to the dialog which asks the user (which would be a Good Thing > (TM), anyway) .. > > There's no mechanism in place to disable the feature. We can introduce > one, though I fear you have no time to wait for what I would consider > the cleanest solution ;-) (namely creating an infrastructure for > drivers to be deployed into OOo, together with a set of configuration > based "meta-data" about the supported functionality of the driver). > > Usually, disabling (or changing) a certain behavior is done by flags > saved at the data source / database document. Would this be sufficient > for you? I.e., everybody creating a new database document using your > driver would need to do this setting once. (And perhaps we can > introduce a mechanism to let the driver tell defaults for certain > settings.) A flag saved at the data source / database document and supplying it's default from within the driver is absolutely sufficient for our needs. :-) > Alternatively, it would be possible to let the driver in general tell > that a certain UI feature is disabled, but as said, there's no > infrastructure in place for this at all - we would need to respect > both the data source and the driver settings, where currently only > data source settings are respected. I couldn't figure out how large the difference in development effort is, but from what have written I rather tend to your first suggestion at the moment. Maybe your second suggestion could be implemented as long term solution later on. Do you intend to change the driver infrastructure of OOo at the near future nevertheless? I think I have seen a document regarding this somewhere on www.openoffice.org, but I didn't realize if it was more a conceptual idea or the really intended approach for future releases of OOo. And one more question, again ;-) I have compiled our driver according to the software requirements on http://tools.openoffice.org/dev_docs/build_linux.html#BuildInstructions on a RHEL4 and tried to install it in OOo 2.4 and 2.4.1 on different Linux distributions. If I install OOo from the install packages on www.openoffice.org everything works fine, but if I install it from the software repositories of the distributions OOo freezes when I try to connect to a database. Is this expected? Do I need to compile the driver in a special way to support the OOo builds in the software repositories of the distributions? Are they doing such big changes to their builds so that the driver won't work with them? I didn't realize that before. Would be nice to have only one driver for the x86 Linux platform independent of the distribution, if possible. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Frank, > Which brings me to the following question: What you do currently - is > this intended to be contributed back to the core code base? That is, > if you do changes to Base's code base outside your driver, then you > would either need to build an own OOo containing those changes, or > contribute them to the project for inclusion in the next release. I didn't do any changes at Base's code base outside the driver so far, but nevertheless we would definitely like to contribute the driver back to the core code base :-) Most of the driver's functionality work's fine, we are still doing a lot of quality assurance, but possibly there is a chance to get the driver into the next release. Can you tell me what the usual procedure when contributing something back to the core code base is? Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hello Michael, > I would like to prevent that OOo Base asks if it should delete a column > and append a new one, when the column definition can't be modified. Is > it possible to do this from within the driver or switch it of in one of > Base's option dialogs (I didn't see anything like this, but maybe I > overlooked it)? There are two problems with this. First is that if the > user has entered data into the column before the data is gone when the > column is deleted and OOo Base shows no respective warning. Second is > that in certain cases Ingres can't append a column to an existing table, > for example if the column is not null and it has no default value. So I > think it would be better to disable this feature when using Ingres. If the problem would only be the missing warning, I'd vote for adding it to the dialog which asks the user (which would be a Good Thing (TM), anyway) .. There's no mechanism in place to disable the feature. We can introduce one, though I fear you have no time to wait for what I would consider the cleanest solution ;-) (namely creating an infrastructure for drivers to be deployed into OOo, together with a set of configuration-based "meta-data" about the supported functionality of the driver). Usually, disabling (or changing) a certain behavior is done by flags saved at the data source / database document. Would this be sufficient for you? I.e., everybody creating a new database document using your driver would need to do this setting once. (And perhaps we can introduce a mechanism to let the driver tell defaults for certain settings.) Alternatively, it would be possible to let the driver in general tell that a certain UI feature is disabled, but as said, there's no infrastructure in place for this at all - we would need to respect both the data source and the driver settings, where currently only data source settings are respected. Which brings me to the following question: What you do currently - is this intended to be contributed back to the core code base? That is, if you do changes to Base's code base outside your driver, then you would either need to build an own OOo containing those changes, or contribute them to the project for inclusion in the next release. The feasibility of different solutions depends on how you want to handle this. 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]
RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Frank, > Is there a possibility to add some kind of "compatibility switch" to > your DB's JDBC driver? That is, your wrapping driver could add some > parameter (like "report-sequences-as-auto-increment=true" or whatever > fancy name you can imagine) to the connection URL, and your JDBC > driver would use this to control the behavior of isAutoIncrement. I think this would be possible, but unfortunately our JDBC driver guy is not very happy with introducing this change in the JDBC driver at the moment. > If this doesn't work, I would vote for introducing a generic mechanism > in OOo's JDBC bridge (let me call it "bridge" instead of "driver", > since it effectively bridges from JDBC to SDBC, and to not confuse it > with a "real" JDBC driver) for manipulating the result set meta data, > and then employ this mechanism from your wrapping driver. > > As an example, consider the type info returned by the > DatabaseMetaData. > The JDBC bridge (and in particular the ODatabaseMetaDataBase class in > connectivity/source/commontools/TDatabaseMetaDataBase.cxx) supports a > setting "TypeInfoSettings" (passed in the PropertyValue sequence upon > connecting), which is used to effectively transform the type > information as retrieved from the database. So, if we have a > database/setup which needs to fake the type information, this (to a > certain extent) can be done by simply creating a proper > TypeInfoSettings value. > > Something similar could perhaps be done for the result set meta data. > If we have a setting which captures the "when the default value of a > column is 'sequence_name.nextval', then return 'true' in > isAutoIncrement" rule, then your wrapping driver could pass this > setting to the JDBC driver. > > I suppose the RowFunctionParser in > connectivity/source/*/RowFunctionParser.* already does almost or all > of what is needed to create such a rule. Then only the > ResultSetMetaData implementation of the JDBC bridge needs to accept > and respect such a setting. Sounds great, this is a far more neat approach than anything that came to my mind. I have duplicated all the classes of the JDBC bridge in my driver now, which works fine, but it is really nasty considering the code duplication. Before starting anything new I need discuss this with my project leader, who was on vacation for the last week and should be back at work tomorrow. One more thing: I would like to prevent that OOo Base asks if it should delete a column and append a new one, when the column definition can't be modified. Is it possible to do this from within the driver or switch it of in one of Base's option dialogs (I didn't see anything like this, but maybe I overlooked it)? There are two problems with this. First is that if the user has entered data into the column before the data is gone when the column is deleted and OOo Base shows no respective warning. Second is that in certain cases Ingres can't append a column to an existing table, for example if the column is not null and it has no default value. So I think it would be better to disable this feature when using Ingres. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Michael, > first of all thanks for your response. I think I forgot to tell this, > as I'm usuallyworking from Monday to Wednesday or Thursday only, > it may take some time till I respond to the mails here. As you might have noticed, my answers are delayed, too - I do not work on Fridays, and sometimes not on Thursdays (parental part time, or however this is called in English). > Now towards the weird driver architecture. You are right, my driver > does not inherit from the MySQL driver, it's rather inspired by the > MySQL driver and wraps around the driver I inherit from the JDBC driver. > The wrapping is to provide some SDBCX services in addition to the SDBC > services of the driver I inherit from the JDBC driver, pretty similar to > the MySQL driver providing SDBCX services in addition to the SDBC > services of JDBC driver. Okay, this part is slightly ugly, but hard too improve without reasonable effort. > The inheritance from the JDBC driver is mainly > to overwrite the isAutoIncrement() Method of the XResultSetMetaData > interface which the JDBC driver implements. Now this part is *really* ugly :) The JDBC driver can change in its ABI at any time without notice, since it's considered an internal component. When you have a driver which links against the JDBC driver and is not part of the core source tree, this driver will sooner or later become non-functional. Also, even if your driver where part of the core source, I would have headaches with exporting all its classes and implementation structure "just" to override such a single facet. Is there a possibility to add some kind of "compatibility switch" to your DB's JDBC driver? That is, your wrapping driver could add some parameter (like "report-sequences-as-auto-increment=true" or whatever fancy name you can imagine) to the connection URL, and your JDBC driver would use this to control the behavior of isAutoIncrement. If this doesn't work, I would vote for introducing a generic mechanism in OOo's JDBC bridge (let me call it "bridge" instead of "driver", since it effectively bridges from JDBC to SDBC, and to not confuse it with a "real" JDBC driver) for manipulating the result set meta data, and then employ this mechanism from your wrapping driver. As an example, consider the type info returned by the DatabaseMetaData. The JDBC bridge (and in particular the ODatabaseMetaDataBase class in connectivity/source/commontools/TDatabaseMetaDataBase.cxx) supports a setting "TypeInfoSettings" (passed in the PropertyValue sequence upon connecting), which is used to effectively transform the type information as retrieved from the database. So, if we have a database/setup which needs to fake the type information, this (to a certain extent) can be done by simply creating a proper TypeInfoSettings value. Something similar could perhaps be done for the result set meta data. If we have a setting which captures the "when the default value of a column is 'sequence_name.nextval', then return 'true' in isAutoIncrement" rule, then your wrapping driver could pass this setting to the JDBC driver. I suppose the RowFunctionParser in connectivity/source/*/RowFunctionParser.* already does almost or all of what is needed to create such a rule. Then only the ResultSetMetaData implementation of the JDBC bridge needs to accept and respect such a setting. 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]
AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Frank, > One thing to mention is that the description text and the default > value, as you see them in the UI, might not be what you expect them > to be. > That is, those values are completely client-side at the moment, even > if the underlying database would support them, to. So, whatever you > enter here, is not sent to the database, it's just used in Base's own > UI. I realized that, but it also makes me wondering why it seems to work well with HSQLDB, but not with MySQL and Ingres, in case the code is the same. I will try to dig a bit more into that and enter a issue for it. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Frank, first of all thanks for your response. I think I forgot to tell this, as I'm usuallyworking from Monday to Wednesday or Thursday only, it may take some time till I respond to the mails here. Now towards the weird driver architecture. You are right, my driver does not inherit from the MySQL driver, it's rather inspired by the MySQL driver and wraps around the driver I inherit from the JDBC driver. The wrapping is to provide some SDBCX services in addition to the SDBC services of the driver I inherit from the JDBC driver, pretty similar to the MySQL driver providing SDBCX services in addition to the SDBC services of JDBC driver. The inheritance from the JDBC driver is mainly to overwrite the isAutoIncrement() Method of the XResultSetMetaData interface which the JDBC driver implements. This is because Ingres does not know autoincrement columns such as MySQL, but it knows sequences which allow us to fake autoincrement columns. To do so instead of put the word "auto_increment" behind the datatype in the create table statement executed from OOo Base, we create a sequence which produces the autoincrement values and assign "sequence_name.nextval" as default value to the column that should behave like an autoincrement column by putting "default value sequence_name.nextval" behind the datatype in the create table statement. The problem is that the underlying Ingres JDBC driver for the SDBC-JDBC bridge driver will always return false for isAutoIncrement(), which is used by OOo Base to determine whether a column should be displayed as autoincrement column in the table editing view or forms, but we need it to return true for columns with the default value "sequence_name.nextval", so we overwrite it accordingly. I hope this helps to understand what I'm doing. As said before, I have no better idea to resolve this problem without inheriting from the JDBC driver unfortunately. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke, I didn't get the chance to finish the case sensitivity problem with Ingres yet, but meanwhile I have discovered other things and probably at least one of them is worth an issue. For some reason Base can't handle values in long varchar columns that exceed a length of 65535 characters, although most databases can. Don't know if this is desired behavior or not. Possibly this is wanted because some databases, for example MS Access, have a limited of 65535 characters for long varchar columns. Unfortunately that is not the worst thing I discovered. Try the following using Base and the SDBC-JDBC driver with MySQL and Ingres database: Copy a string that exceeds 65535 characters into a long varchar column. The string is cut and a warning is displayed, which is good, but surprisingly the string is cut to noticeably less than 65535 characters. The exact number of characters to which the string is cut seems depend on how long the string you try to insert is. Then fill the long varchar column with additional characters until you reach 65535 characters or more and click the save button. Now close the table and reopen it. You will see that the value you edited before is erased. I think this is be a really bad bug, as it might destroy the users data. Last but not least, performance. Editing long varchar values in the table view is very slow, editing them in forms is a lot better. Maybe this is okay as forms work fine and improvement is difficult. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
