On 2011-11-19, at 8:18 AM, MJ Ray wrote:
Mason James <mtj@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