Re: [Libreoffice] ODBC handles, a quibble
On Sun, 2011-10-09 at 15:09 +0200, Lionel Elie Mamane wrote: Just ignore the function that diff reports :) (Or send a patch to GNU diffutils so that it recognises C++ syntax ;-) ) Thank you for your reassurance that I am not hallucinating. All-in-all, I guess my attention is better applied closer to LibreOffice itself. Terry. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
On Sun, 2011-10-09 at 15:27 +0200, Lionel Elie Mamane wrote: I did not read *all* of it, but it seems the ODBC documentation contains no such madness. So my guess is that the Microsoft implementation of SQL-CLI that is ODBC defines that handles cross compilation units. IMHO the other implementations of ODBC better follow that, or I'm not sure it is worth supporting them in LibreOffice. Not worth supporting: That is a nice, polite way of putting it. If we knew what drivers or driver managers violate the common expectation, it might well be worthwhile to warn against using them. But I can think of no better way to find them than to wait for complaints about something not working. It all sounds quite unlikely. And on a nitpicking level, ODBC has a relationship to ISO/IEC 9075-3:1995, not 9075-3:2006 :) But indeed I guess that 9075-3:1995 contains the same language. Yes, the 1995 version has exactly the same sentence. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
On Tue, Oct 04, 2011 at 12:27:11PM -0400, Terrence Enger wrote: On Tue, 2011-10-04 at 11:27 +0100, Michael Meeks wrote: On Fri, 2011-09-30 at 14:13 -0400, Terrence Enger wrote: My interest is in the fractions of seconds in times and timestamps, an interest provoked by bug 34309 Error on importing a timestamp field from db2 via ODBC https://bugs.freedesktop.org/show_bug.cgi?id=34309. Nice - thanks for your help testing there, looks like we're blocking on some input from Lionel - I guess if we don't get that in a few days, and it seems to work we should just commit your patch :-) (*) Caolán's patch fixes also ODatabaseMetaDataResultSet::getTimestamp. (Hunh? Why does the diff say that the changed line is in ODatabaseMetaDataResultSet::getShort? I still think the changed function is getTimestamp.) My guess is that diff gets confused by C++ syntax it does not recognise; it knows only C syntax. My guess in this case is that the part that confuses it is the namespace separator ::; it does not recognise getString, getTime, getTimestamp as new functions because their return type starts (or contains) ::. Just ignore the function that diff reports :) (Or send a patch to GNU diffutils so that it recognises C++ syntax ;-) ) -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
On Thu, Sep 29, 2011 at 12:02:01PM -0400, Terrence Enger wrote: Silly me! While reading some of the LibreOffice code for ODBC connections, I started to look at ... ISO/IEC FCD 9075-3:2006(E) Title: Information technology - Database Languages - SQL - Part 3: Call-Level Interface (SQL/CLI) http://jtc1sc32.org/doc/N1501-1550/32N1527T-text%20for%20FCD%209075-3.pdf This passage in section 4.4.1 Handles catches my eye: The validity of a handle in a compilation unit other than the one in which the identified resource was allocated is implementation-defined. I did not read *all* of it, but it seems the ODBC documentation contains no such madness. So my guess is that the Microsoft implementation of SQL-CLI that is ODBC defines that handles cross compilation units. IMHO the other implementations of ODBC better follow that, or I'm not sure it is worth supporting them in LibreOffice. And on a nitpicking level, ODBC has a relationship to ISO/IEC 9075-3:1995, not 9075-3:2006 :) But indeed I guess that 9075-3:1995 contains the same language. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
On Tue, 2011-10-04 at 12:27 -0400, Terrence Enger wrote: (*) Caolán's patch fixes also ODatabaseMetaDataResultSet::getTimestamp. (Hunh? Why does the diff say that the changed line is in ODatabaseMetaDataResultSet::getShort? ... I still think the changed function is getTimestamp.) This is just an artefact of patch itself, the text on the line after @@ can be somewhat irrelevant to what actually get patched. I pushed my patch, mostly because its the simplest, and Lionel can double-check it later at his leisure. (*) Both patches discard milliseconds. I *guess* this is the right thing to do, but would welcome others' opinions. Anyway, there is no more need for the TODO comment saying to ask this question. We're kind of stuck there without a lot of work because 100ths of a second is as good as our existing timestamps support. Probably ok given given http://support.microsoft.com/kb/263872 C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
On Wed, 2011-10-05 at 13:31 +0100, Caolán McNamara wrote: I pushed my patch, mostly because its the simplest, and Lionel can double-check it later at his leisure. I agree. (*) Both patches discard milliseconds. I *guess* this is the right thing to do, but would welcome others' opinions. Anyway, there is no more need for the TODO comment saying to ask this question. We're kind of stuck there without a lot of work because 100ths of a second is as good as our existing timestamps support. Probably ok given given http://support.microsoft.com/kb/263872 aside Heh. The microsoft page warns me This article applies to a different operating system than the one you are using. Article content that may not be relevant to you is disabled. Take that, you lefties who care about cross-platform development! For comparison, I tried inserting a value with too much precision into a TIMESTAMP(4) field in PostgreSQL. The result was silent truncation, at least as far as I can see by selecting the field in psql. /aside Actually, I was questioning the decision to truncate milliseconds rather than rounding to the nearest hundredth. It common (but not overwhelmingly common) to round values when a conversion loses precision, but truncation is consistent with the common treatment of times outside programming. I guess I just answered my question: when programming and the outside world bump into each other, the real world should win. Thanks, Terry. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
On Fri, 2011-09-30 at 14:13 -0400, Terrence Enger wrote: My interest is in the fractions of seconds in times and timestamps, an interest provoked by bug 34309 Error on importing a timestamp field from db2 via ODBC https://bugs.freedesktop.org/show_bug.cgi?id=34309. Nice - thanks for your help testing there, looks like we're blocking on some input from Lionel - I guess if we don't get that in a few days, and it seems to work we should just commit your patch :-) It's normally better (FWIW) to post patches to the list with a [PATCH] in the Subject - so they annoy more people into action. Wondering what's next on the hit list, there are rumours of badness with the form / reports designer out there apparently ;-) Thanks ! Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
I am sorry for the length of this answer; hope it is worth reading. On Tue, 2011-10-04 at 11:27 +0100, Michael Meeks wrote: On Fri, 2011-09-30 at 14:13 -0400, Terrence Enger wrote: My interest is in the fractions of seconds in times and timestamps, an interest provoked by bug 34309 Error on importing a timestamp field from db2 via ODBC https://bugs.freedesktop.org/show_bug.cgi?id=34309. Nice - thanks for your help testing there, looks like we're blocking on some input from Lionel - I guess if we don't get that in a few days, and it seems to work we should just commit your patch :-) Well, the bug has been around for three years, so it cannot be very urgent. Moreover, I have some hesitations ... (*) Caolán's patch gives smaller code and looks like it would require much less work from the machine, and in every case I have seen it gives the same result as my patch. All these factors favour Caolán's patch. (*) Caolán's patch fixes also ODatabaseMetaDataResultSet::getTimestamp. (Hunh? Why does the diff say that the changed line is in ODatabaseMetaDataResultSet::getShort? I still think the changed function is getTimestamp.) My patch does not do this, merely because I do not know where to look for a resulting difference in the output. So, my patch is deficient in this respect. Perhaps it would be in order to push down the fix by creating either - a constructor DateTime(TIME_STRUCT) to encapsulate the changed factor in the calculation of hundreths of a second, or - a constructor DateTime(rtl::OUString) to encapsulate the string manipulations. (*) In the hope of attracting critical feedback (but constructive, of course: this is after all LibreOffice grin /), I sprinkled the code liberally with questions and comments. Most conspicuously, - I cite the X/Open reference manual. I have not seen any comparable citation in LO code. Perhaps the citation does not belong in the code at all. - I express my own doubts about that manual. This is a more personal expression than anything I have noticed elsewhere in the code. Does it belong? - Since I have just asked these questions here, there is no more need for the TODO comment saying to ask these questions grin /. (*) I think I remember reading that a database may return a time with fractions of a second, but I do not know any database driver which actually does this. Is my memory mistaken? Is there a known database driver which delivers fractions of a second? Neither patch addresses this issue. Again, the TODO comment can go away. Perhaps the question itself should go away, too. (*) Both patches discard milliseconds. I *guess* this is the right thing to do, but would welcome others' opinions. Anyway, there is no more need for the TODO comment saying to ask this question. (*) Is this really all it takes to fix the bug? It seems too simple. Maybe I have spent too many decades working on less well organized code. A couple of forays into opengrok turned up so much that I gave up in despair. Then there is the question of whether Caolán's ODBC_FRACTION_UNITS_PER_HSECOND should be calculated the precision (or, do I mean the scale) of the column. I simply do not want to go there. It's normally better (FWIW) to post patches to the list with a [PATCH] in the Subject - so they annoy more people into action. My reticence was deliberate. With all the questions and difficulties that my patch has, I offer it more as an earnest of good intentions than as completed work. Wondering what's next on the hit list, there are rumours of badness with the form / reports designer out there apparently ;-) I heard those rumours too, but I do not think I am competent to address them. UI's are complex beasts. Of course, I shall try to deal with any suggestions arising from the questions and hesitations I wrote about above. My immediate task is to complete a build from recent master. If Calc still exhibits some funny (IMO) cursor movement, I shall work toward filing a bug report. After that, perhaps ... (*) Programmed testing of some part of Base. The second^h^h^h^h^h^hthird step here would be reading about the testing infrastructure. So, it will be a while before I can expect to do anything more useful than bother busy people with questions sigh /. (*) An arbitrarily chosen TODO from one of the hundred or so thrown up by `git grep` of connectivity and dbaccess. This seems a bit less daunting, but that is only because I know absolutely nothing about what I am talking about sigh /. Thanks ! Michael. Thank you, Michael, for your continual patience with a noob. Terry. ___ LibreOffice mailing list
Re: [Libreoffice] ODBC handles, a quibble
On 10/04/2011 06:27 PM, Terrence Enger wrote: (*) In the hope of attracting critical feedback (but constructive, of course: this is after all LibreOffice grin /), I sprinkled the code liberally with questions and comments. Most conspicuously, - I cite the X/Open reference manual. I have not seen any comparable citation in LO code. Perhaps the citation does not belong in the code at all. - I express my own doubts about that manual. This is a more personal expression than anything I have noticed elsewhere in the code. Does it belong? I would consider such comments fully appropriate in the code base. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
On Mon, 2011-10-03 at 11:06 +0100, Caolán McNamara wrote: On Thu, 2011-09-29 at 12:02 -0400, Terrence Enger wrote: The validity of a handle in a compilation unit other than the one in which the identified resource was allocated is implementation-defined. If I had to guess, I'd take it as something alone the lines of handles may be implemented as pointers, and in windows 16 they might be implemented as near pointers. That kind of thing. That makes sense. The problem with segmented architectures is not segments; the problem is *small* segments. grin / Anyway, isn't it the case that ODBC is *based* on the SQL/CLI, so it layers additional features and lesser constraints on top of it. Ah, yes. I remember being bothered by a lack of documentation saying that the two are the same. Over the years, the difference slipped my mind. Thanks, Terry. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
Hi Terrence, First - it's awesome to have you looking at, reading and caring about the ODBC code - that's brilliant. On Thu, 2011-09-29 at 12:02 -0400, Terrence Enger wrote: Silly me! While reading some of the LibreOffice code for ODBC connections, I started to look at ... .. This passage in section 4.4.1 Handles catches my eye: The validity of a handle in a compilation unit other than the one in which the identified resource was allocated is implementation-defined. Yikes! How can any large (or moderate sized) project avoid assuming the validity of ODBC handles across the boundaries of compilation units ? Well - particularly since there is no possible work-around beyond munging everything into one big beast of a C++ file ;-) LibreOffice seems to assume continued validity; Sure - anything else would seem to imply a madness on the side of the ODBC implementation author that would amount to perversity ;-) are these methods really going (at run-time) to walk up the stack, find where the caller came from, work out which object file it was and then do 'undefined' things if the next call on the handle comes from somewhere else. (*) What ODBC driver invalidates an ODBC handle across compilation unit boundaries? I have no idea - but unless I totally misunderstood this I'd be amazed if any did. (*) By what magic can the driver know anything about its caller's compilation units, anyway? Quite ;-) I mean - in the same DSO might be feasibly detectable but ... Will some kind soul here please tell me that I need not worry about such things? Certainly - you don't need to worry about such things ;-) most of the legacy bugs in the LibreOffice code are of the more startlingly obvious kind (in my experience), and in the connectivity world often have a helpful: // TODO - actually implement this ;-) next to them. Does that help ! Out of interest which bug / feature are you chasing ? (and do you hang out on IRC ? :-). All the best, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
Le 29/09/11 18:02, Terrence Enger a écrit : Hi Terry, Not sure whether what I have in my memory has any bearing on this, but... I remember discussions with Frank Schoenheit back from the OOo days about mysql ODBC driver misbehaviour because it erroneously reported some status and functionality to SBDC/SDBCx, so when of course something else in the code tried to use them...well, they naturally failed, blew up or caused some other untold and unexpected madness. I can't remember now whether the driver was understating or overstating its capacities, but it did cause problems. Like I said, not really sure that this is related to your question, but it might be. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
On Fri, 2011-09-30 at 16:25 +0200, Alexander Thurgood wrote: Le 29/09/11 18:02, Terrence Enger a écrit : Hi Terry, Not sure whether what I have in my memory has any bearing on this, but... I remember discussions with Frank Schoenheit back from the OOo days about mysql ODBC driver misbehaviour because it erroneously reported some status and functionality to SBDC/SDBCx, so when of course something else in the code tried to use them...well, they naturally failed, blew up or caused some other untold and unexpected madness. I can't remember now whether the driver was understating or overstating its capacities, but it did cause problems. Like I said, not really sure that this is related to your question, but it might be. Not directly related, I think, but it does remind me that I should pay some attention to mysql. My interest is in the fractions of seconds in times and timestamps, an interest provoked by bug 34309 Error on importing a timestamp field from db2 via ODBC https://bugs.freedesktop.org/show_bug.cgi?id=34309. However, it looks like mysql stopped supporting fractions of seconds with version 4.1, released in October, 2004. Does anybody care at all about the behaviour of versions that old? If anybody does care, how would I know? Thanks, Terry. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] ODBC handles, a quibble
Silly me! While reading some of the LibreOffice code for ODBC connections, I started to look at ... ISO/IEC FCD 9075-3:2006(E) Title: Information technology - Database Languages - SQL - Part 3: Call-Level Interface (SQL/CLI) http://jtc1sc32.org/doc/N1501-1550/32N1527T-text%20for%20FCD%209075-3.pdf This passage in section 4.4.1 Handles catches my eye: The validity of a handle in a compilation unit other than the one in which the identified resource was allocated is implementation-defined. Yikes! How can any large (or moderate sized) project avoid assuming the validity of ODBC handles across the boundaries of compilation units? LibreOffice seems to assume continued validity; for example connectivity/source/drivers/odbcbase/OConnection.cxx line 640 allocates a statement handle which connectivity/source/drivers/odbcbase/OStatement.cxx line 94 copies for use later. So, I wonder ... (*) Is there a better reference document for me to look at? (*) What ODBC driver invalidates an ODBC handle across compilation unit boundaries? (*) By what magic can the driver know anything about its caller's compilation units, anyway? Will some kind soul here please tell me that I need not worry about such things? Thanks, Terry. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
