Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Moin Micha, Michael Strobel wrote: Hi Ocke, That would be great. But an issue where you attach the bugdoc would even be better :-) I got the following mail from our JDBC driver developer, which makes me think it's not an issue. What do you think? --- snip --- Working with LOB columns is extremely difficult due to many restrictions on when the data can or must be accessed. Autocommit makes it very difficult to handle LOB locators. I do not recommend enabling locators during autocommit, especially with a cursor mode of 'multi'. Simulating autocommit to support multiple open cursors (which Ingres does not support) results in full transaction commits being issued by the driver. A full commit invalidates a LOB locator, which is probably the cause of your problems. With locators disabled, the application must process the streamed LOB data. This restricts what actions may be taken on the connection. The application is attempting to issue a new query when there is LOB data still to be processed. The driver protects the data stream with locks, which is causing a dead-lock in the application. Most generic applications are not disciplined enough to follow JDBC portability guidelines of reading all columns in order and only once when processing result-sets. My suggestion is that you do not enable lob locators (use default settings), but that you enable the caching of LOB data. This will avoid the transaction conflicts with locators and restrictions on processing LOB data streams. The downside is that LOB data will need to fit in memory. Please review the BLOB Column Handling section of the JDBC chapter in the 2006r3 Connectivity Guide. --- snip --- The suggestion to enable the caching of LOB data works for me. Maybe this is what databases which run out of the box with OO do by default. While doing more tests of the driver unfortunately I discovered the following two problems: When I click the save button in the table design view for a new table without having set a primary key beforehand a dialog appears which allows me to let OO create a additional column 'ID' as primary key. That's fine so far. When I click the 'Yes' Button in the dialog the create table statement is executed correctly, but OO doesn't recognize the new table until the tables are refreshed manually by clicking 'View -> Refresh Tables'. In table design view you may again click the save button as OO doesn't recognize that the table is created successfully. Clicking the button again produces an SQL error as the table already exists. Similar thing happens when I use the table wizard to create a table. Clicking finish executes the create table statement correctly, but the table isn't displayed in the list of tables and the wizard doesn't close itself. Clicking the finish button again produces an SQL error as the table already exists. Any ideas what might be the root cause? I did a bit code reviewing but found nothing suspicious so far. Do you know what queries are usually executed after saving a table? Possibly there is one that doesn't work with Ingres in these situations. After save the table we ask the db metadata with getTabes and the parameter filled for the table we saved. May be that doesn't return no information. When you do a refresh it is mostly like creating a new connection. 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
Re: [dba-dev] Re: data aware controls for basic dialogs
Hi Frank, On Fri, 2008-06-06 at 23:32 +0200, Frank Schönheit wrote: > Hi Noel, > > please note I answer the mail in dev@dba.openoffice.org, which really is > the more appropriate for this kind of discussion. Please also stick to > this list - doing all this in private communication sounds like a waste > of knowledge to me. Thanks. okay. > > Just a quick note ( well begging letter perhaps ) to say that I really > > really want to get data-aware controls working for basic dialogs. > > Oh - challenging. :-) hopefully not too challenging > > I did try with some creative harcoding ;-) and met with some success > > ( and some odd behaviour e.g. some hangs etc. but in general it worked ) > > So, I wonder am I on the right or wrong track with this approach? what > > do you think is the right way to go?. What are the obvious pitfalls? > > What I would like to do initially at least is to get the basic dialog to > > use the form control ComboBox, ListBox instead of the standard uncontrol > > ones. > > You don't mention what exactly you did, so I can't answer your question > whether you're on the right track ... basically I created a ( calc ) document with a basic dialog with a ListBox control, in the import code ( xmlscript ) I hardcoded creation of the "com.sun.star.form.component.DatabaseListBox" instead of the normal com.sun.star.awt.UnoControlListBoxModel ( so I saw the code you mentioned regarding trying the global multiservicefactory if the dialog factory failed ). I had some other test code that used the basic dialog and in that code I hardcoded values for the model properties 'ValueBinding' and 'ListEntrySource'. As I said it seemed more or less to work. The ListBox is populated with the values in the range I specified, selecting entries in the ListBox changed the value in the bound cell, so at least that is promising > > The major problem I anticipate is that the form control models are not > prepared to live in a container which is *no* data aware form. This > might or might not be a problem ... > First, IIRC the dialog model does *not* set itself as parent of its > control models - does it? If it *does*, then any access in the form > control models to their parent component must be checked, as it is > potentially problematic. I think you recall correctly, at least the standard unocontrol models ( in toolkit ) don't offer a XChild interface, so although I can't say for certain that the Dialog code tries to set itself as parent I would think it is unlikely ( I will look later to confirm ). > If the dialog model does *not' set itself as parent, then the form > controls might in fact work in the dialog, but without the > database-related functionality. > > If you're interested in the cell binding stuff only, for the moment, but maybe other properties might become interesting also > this might be > sufficient. The cell binding implementations are much more modern than > the database bindings, so I have hope here. In particular, cell bindings > are a special case of "value bindings" (see the css.form.binding > module), which are to be implemented external to the form control > models, and have a very precise interface to those models. > At the opposite, database bindings are implemented inside the form > control models, and parts of the functionality is taken from the data > forms, which thus are expected to be the parent of a form control model. > Though some refactoring over the years improved the situation here, > that's still a mess in some parts. I guess what I was trying to tease out in my clumsy way is, do you think it worth moving the 'value binding' bits out forms to the 'base' control model in toolkit. I worry about the form control bindings you mention and whether they could cause grief ( I did say in the last mail that I did notice some hangs, particularly when using the Xray tool to introspect the control model ) I didn't really investigate more at this stage. The parent issue also concerns me, ok, I think at the moment there isn't a problem because I suspect the Dialog doesn't set itself as a parent. But I would hope there is a future when the Dialog code is more containment aware and would set itself as parent > > > Another item on your list should be the property browser, implemented as > css.inspection.ObjectInspector in extensions/source/propctrlr some useful info there indeed, I will of course take note. > In any case, I *strongly* recommend you doing your implementations in a > non-product build (configure switch --enable-dbgutil), the code is paved > with assertions which in a non-product build will report you when > something is not as expected. does this give you something extra than just building with debug? ( e.g. 'build debug=t' ) or is this just necessary for windows builds? Does one need to build the entire office with this switch ( e.g. from the configure ) or is it possible to be a bit more selective? > > > > of course there are additional things to think about like
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke, > That would be great. But an issue where you attach the bugdoc would > even be better :-) I got the following mail from our JDBC driver developer, which makes me think it's not an issue. What do you think? --- snip --- Working with LOB columns is extremely difficult due to many restrictions on when the data can or must be accessed. Autocommit makes it very difficult to handle LOB locators. I do not recommend enabling locators during autocommit, especially with a cursor mode of 'multi'. Simulating autocommit to support multiple open cursors (which Ingres does not support) results in full transaction commits being issued by the driver. A full commit invalidates a LOB locator, which is probably the cause of your problems. With locators disabled, the application must process the streamed LOB data. This restricts what actions may be taken on the connection. The application is attempting to issue a new query when there is LOB data still to be processed. The driver protects the data stream with locks, which is causing a dead-lock in the application. Most generic applications are not disciplined enough to follow JDBC portability guidelines of reading all columns in order and only once when processing result-sets. My suggestion is that you do not enable lob locators (use default settings), but that you enable the caching of LOB data. This will avoid the transaction conflicts with locators and restrictions on processing LOB data streams. The downside is that LOB data will need to fit in memory. Please review the BLOB Column Handling section of the JDBC chapter in the 2006r3 Connectivity Guide. --- snip --- The suggestion to enable the caching of LOB data works for me. Maybe this is what databases which run out of the box with OO do by default. While doing more tests of the driver unfortunately I discovered the following two problems: When I click the save button in the table design view for a new table without having set a primary key beforehand a dialog appears which allows me to let OO create a additional column 'ID' as primary key. That's fine so far. When I click the 'Yes' Button in the dialog the create table statement is executed correctly, but OO doesn't recognize the new table until the tables are refreshed manually by clicking 'View -> Refresh Tables'. In table design view you may again click the save button as OO doesn't recognize that the table is created successfully. Clicking the button again produces an SQL error as the table already exists. Similar thing happens when I use the table wizard to create a table. Clicking finish executes the create table statement correctly, but the table isn't displayed in the list of tables and the wizard doesn't close itself. Clicking the finish button again produces an SQL error as the table already exists. Any ideas what might be the root cause? I did a bit code reviewing but found nothing suspicious so far. Do you know what queries are usually executed after saving a table? Possibly there is one that doesn't work with Ingres in these situations. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
