[Koha-devel] Update database changes proposal [IMPORTANT]

[Mason James]

On 2011-11-19, at 8:18 AM, MJ Ray wrote:

> Mason James <mtj at kohaaloha.com>
>> 
>> i think if we want to do Ian's suggested check/apply/roll-back idea
>> for DB changes, we will indeed need to use .pl files not .sql files
>> for new patches
> 
> I'm not sure about that either.  Surely it could be done by setting
> SQL session variables in the updatedatabase that loads the sql file
> and conditionals in the SQL?
> 
> But anyway, what about supporting both?  If I'm wrong and .sql has to
> be trivially converted to .pl one day, it's not that awful.  If I'm
> right and we can eventually replace all .pl with .sql, that makes
> updating a lot cleaner and safer.
> 
> Regards,
> -- 
> MJ Ray


ok, i can easily imagine future situations where .sql patch files alone just *won't* work for upgrades
 (lets ignore Paul's previous example)

the situation i am imagining is where a patch requires a database change to made via say... an internal Koha subroutine().
 (like an update made to all bib or item records, via calls to the ModBiblio() or ModItem() subroutines)

now.. how could an .SQL only solution achieve this? - its impossible, right?

 - using .pl patches, with a *combination* of perl and sql, would allow us the best of both options
 - using .sql patches alone, means a patch won't be able to use any internal Koha subroutines?


i realize i was originally keen on an .sql solution...
but after more thought, i believe an .sql solution will be too limited for some upgrade tasks

using perl, we wont *ever* bump into this potential limitation. 
do i have a valid point here?


cheers, Mason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20111120/790a20ba/attachment-0001.pgp>