Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

2008-06-09 Thread Ocke Janssen

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

2008-06-09 Thread Noel Power
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

2008-06-09 Thread Michael Strobel
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]