On 04/04/08 09:43, Dan Pascu wrote: > On Friday 04 April 2008, Juha Heinanen wrote: > >> is there something equivalent of mysql back quotes in oracle? if so, i >> suggest that they are used instead or renaming existing fields. >> >> if not, then i don't see a choice for renaming as long as we don't have >> configurable database creation scripts. >> > > Thank you, > > That was my initial question and the point I made. It would be very much > prefer to use quoting if available than to rename columns after they were > in use for more than 2 releases. This can even be done with the current > db schema generation. While it's not the most straightforward approach, > it works. For example, I have this column definition in a custom table > where a column name is a mysql keyword and there is no issue with it: >
Because it is not used by openser,, will not work now -- my point I made in the previous email is that yes, quoting is a preferable way, but it requires changes in the db modules and i don't know if can be done in unixodbc where the db system behind is floating. Another big concern is the openserctl script, where for sql backends have a query to interact with database, needs to be updated as well. I haven't seen a patch yet, but it will be integrated once submitted. > <column id="condition"> > <name>condition</name> > <name db="mysql">`condition`</name> > <type>string</type> > <size>4</size> > </column> > > > Of course I would very much prefer if quoting would be done automatically > for each database type and such constructs would not be needed, but for > the time being if oracle supports quoting it can be done like this. > > One of the issues I saw with almost every release of openser since 1.0.0 > is the major disruptive changes that were in all of them. There was no > release since then where I didn't have to completely rewrite my config > script, alter my db schemas and update applications to use the new db > schemas. The fact that after a release it can take up to a month to > adjust the old environment to the new release and sort out all bugs, > makes it a very innefficient approach when the release cycle is 6 months. > It is why we try to make major releases often, not to accumulate to many radical changes, but I don't see other options. All the software I know and used to configure needed updates to configs to make it work with new major versions, even apache2. Daniel > This is why I would suggest we should generally use a less disruptive > approach to things that minimized the migration path, especially if > available and especially when (like in this case) would completely solve > the problem rather than working it around. > > -- http://www.asipto.com _______________________________________________ Devel mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/devel
