Le Mercredi 17 Août 2005 10:32, Frank Schönheit - Sun Microsystems Germany a écrit : > Hi Éric,
Hi Frank, > As promised earlier, I'm starting to cc [EMAIL PROTECTED] here, since I like > to > keep such general discussions (driver architecture and implementations) > public. I realize that Tobias might not be subscribed to [EMAIL PROTECTED], > so I > try to always remember to "reply-all" instead of "reply" ... Please also > do so, keeing [EMAIL PROTECTED] in the queue this way. OK. > Okay, in this case everything I said about the sdbcx-level Column is > obsolete :). OK, I analysed the other drivers a bit more : - only two drivers declare they offer the sdbcx.Column service (hsqldb and mysql) - there seems to be a Column class in only four drivers (ado, hsqldb, mozab, and mysql) - many drivers instantiate a sdbcx::OColumn (calc, dbase, evoab, file, flat, and mozab) > > No, it's KabResultSet and KStatement that implement XPropertySet. And > > that's correct, see > > http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/ResultSet.html > > http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/Statement.html > > Yes, sure, XPropertySet can be implemented by a lot of classes. OK. > Basically, whenever you see a service description in the API reference > which states it has a property, then you can be sure that the > implementation has at least an XPropertySet (and usually also an > XMultiPropertySet, and often also an XFastPropertySet - both provide > different kinds of property access to the same properties). > > So, if your driver *had* an sdbcx.Column implementation, it would need > the XPropertySet, too. Among ado and mozilla drivers, only the ado driver seems to be doing real property management in class OAdoColumn. mozab/MColumn.hxx contains only two constructor declarations. Am I wrong if I go to the conclusion that only ado driver > > OK. I'm starting to understand the details, but I still do not understand > > what properties are useful for, from a practical point of view. > > If an UNO component has an "attribute" (say "Foo") which can be obtained > by its clients, you have different syntactic ways (each with advantages > and disadvantages) to express this in the UNO API: Aaah, we are at generic uno-level. I thought (naively) that it was something specifically related to database drivers. > - an Interface with a |getFoo| method > in the C++ implementation, this is reflected as method |getFoo| > (well, you could also name this |giveMeTheFoo|, but |getFoo| > has the advantage that generic introspection will recognize it as > attribute - but that's another story) > > - a service which has a property "Foo" > in the C++ implementaiton, this is reflected by implementing the > |XPropertySet| interface (at least), and implementing its > |getPropertyValue| for the argument "Foo" > > - an interface with an attribute Foo > (the concept of attributes at interfaces is old, but extensively used > and recommended only recently, so you might not see this too often) > In the C++ implementation, this is also reflected as method |getFoo| > > So, from "a practical point of view", properties are just one way to > express attributes of a component. OK. What I am still having a hard time to grasp is the final purpose: when are these properties queried in the driver? What happens if I do not implement them correctly? How do I test this stuff? But I think I can answer these questions alone. Tracing the calls to getFastProperty() or whatever should be a good way to start understanding that. > > But never mind, that's not important. > > Oh. > Well, nonetheless I tried to explain it :) Well, it *is* important to me ;-). But I don't want to burn too much of your work time... > There are not much use cases for using a driver directly. Hmmm... I can figure out a Basic macro or a Java program calling the driver directly... > Finally, the most important thing is it *does* work in OpenOffice.org - > not only in the UI, It does. > but also in the higher layers which usually encapsulate access > to the drivers. What do you mean? Can you show me a way to test that? > In general, SDBC is sufficient for most kinds of data access, and > probably also for your driver. SDBCX adds convenience interfaces, > abstractions for some aspects (such as user administration), and > sometimes new features (such as bookmark handling). None of those are > really required to operate your driver in OOo. Right. Please note that it's not too difficult to handle either. User management results in no-operation, bookmark handling is just managing another set of addressees... > So, if you want to strip down your driver to SDBC only, that's perfectly > okay. Also, you would not necessarily need to implement the whole SDBCX, > you could just do selected interfaces/functionality. OK. > Bookmarks might, at some stage, be interesting, since they provide a > mechanism to uniquely identify a row (that's basically the definition of > a bookmark: some blackbox-value interpreted by the driver only, where > different rows have different bookmarks, and the driver can > unambiguously point to a row for a given bookmark.) OK. So it's not really necessary, but it's better to have it. Understood. When you are like me a newcomer to uno, this weak coupling of components is rather surprising. You are used to be _obligated_ to implement pure virtual functions, and to be happy to be _able_ to implement simple virtual functions. There is no such thing like "oh, and there is another interface I could implement". > If result sets don't provide bookmarks, they need to provide a unique > index (for instance a primary key), so OOo has another mechanism to > uniquely identify rows. This is required for update access to result sets. OK. the kab driver doesn't do currently update access, but I will certainly do someday. There is an "identificator" mechanism in KDE's address book which would allow implementing primary keys, but bookmarks wouldn't harm either. > Sure. Personally, I am a big fan of *understanding* code I stea^Wcopy > from somewhere else, even if this means going slower. Yes, copying blindly other people's code would have been simpler, safer and faster. I spent a lot of time removing things, and now I spend a lot of time re-adding them... But at least I know more or less what every line in the driver is about, and I know the driver is not bloated with useless code. > No problem at all. I'm well aware of the fact that the UNO API, > especially for the drivers, is not for the fearful ones. So, receive my > respect for venturing into this area :), and please continue asking, and > I'll try my best answering. Thanks for your mark of respect :-)... and for your patience. Best, --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
