[OpenSER-Devel] SF.net SVN: openser: [3972] trunk

[Daniel-Constantin Mierla]

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