Hi Henning! Tuesday, May 13, 2008, you wrote:
> well, to be correct you proposed not this kind of extension to the DB API. :) > I thought some of your changes were then to heavy for the current state of > the development, e.g. i wanted to postphone them after 1.4. You see that we > still working on the prober integration of db_oracle.. In my opinion, this is not quite so. I could make changes in the code in a couple of days (for example, in a some weekend). Of course, taking into account the 2 or 3 modules that will be able to use them immediately. However, not that easy for me is to compose documentation to these changes in proper English :) > I also suggested that we should discuss this things on the developer list. > Here we've found probably a compromise easier. And i have answered that my English is not good enough to carry out discussions :). I can repeat here my proposals (as a pseudocode) but I can hardly participate in a discussion. > I think the addition on a function like Dan proposed make sense. Here I don't agree. For a number of reasons. 1. inline can appear only if db-engine is defined at the compilation stage, and this is highly undesirable. 2. Perhaps you remember that I have proposed to do without the sql constructions in the modules (all except for db-specific) because different approaches are optimal for different engine, and it is not appropriate to place the db-specific things into modules that have nothing to do with db operation. 3. If I still persuade you :) to introduce the notion "function", not only '='/'<'/'>, into db-api, then the appearance of constructs like the function proposed by Dan will only complicate transition to the new mechanism. In other words, it would be better to do this in a proper way than to make "patches". Whether this should be done now or after the release of 1.4 - this may be the subject of a discussion. ;-) Best regards, Iouri P.S. This answer translate to english not by mine :) _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
