Time  Nick   Message
12:36 hdl    kados ?
12:36 dewey  kados is probably champion alligator-wrestler in 7 counties
12:37 hdl    if you are around, I completed pre-version for member management screens.
12:37 hdl    You can get a test or have someone on it.
12:38 hdl    There are still <p>s and some other stuff to change.
12:38 hdl    But it seems to work.
12:54 hdl    only one template.
12:54 hdl    With tabs.
12:55 hdl    We could add a syspref for quick member entry and make a selection : firstname/surname/cardnumber/catcode/branch/phone/email
12:55 hdl    only
12:56 hdl    But. would endup in having two ways to enter/process data... I donot favour that.
14:56 hdl    root
15:01 paul   owen around ?
15:27 kados  paul: responding to your email now
15:27 kados  hi btw :-)
15:27 paul   hi kados
15:27 kados  we have koha mtg in 40 minutes?
15:27 paul   yes, of course
15:29 paul   while answering to my mail, if you could explain owen last commits, because I don't understand them :-( (the one splitting css to multiple files, that makes intranetstylesheet systempref not work anymore : Koha looks ugly for me now...)
15:33 kados  paul: email sent
15:33 kados  paul: we can discuss that
15:33 kados  paul: it's not in my email
15:33 kados  yes, the stylesheet changes aren't complete
15:34 kados  but we are working rapidly on them
15:34 kados  and should have a description of the changes ready on Wed
15:34 kados  we're also writing a template style guide
15:34 kados  paul: I know it seems like a step backward, but trust me, it will be a much more complete way to handle templates
15:35 kados  when we're done you can apply the drupal theme again quite easily
15:35 kados  (but I think the new default will be much prettier)
15:35 paul   your mail seems to have been lost...
15:35 paul   or arrives by boat maybe ;-)
15:35 paul   gotcha
15:36 kados  paul: get the email yet?
15:36 paul   yep
15:36 kados  cool
15:38 slef   /names
15:38 [K]    *** #koha@FreeNode names: rangi ru55el [K]
15:38 slef   hi all
15:38 paul   hello slef
15:38 kados  hey sle
15:38 kados  slef
15:38 slef   I'm just going to clear my in-tray, should be back before meeting
15:41 paul   kados : seems our positions/goals aren't that far. nice to see it... although i'm still a little bit afraid about the next weeks. However, we are getting more and more confident with git, so we can handle those things better and better.
15:41 paul   our next 2 steps are :
15:41 paul   - investigate cherry picking, to apply official patches when we want
15:42 paul   - build an internal git server, to have (hdl & me) a common branch
15:43 kados  slef: we're counting on you :-)
15:43 paul   kados : could you give me some hints to create a git server ?
15:43 slef   kados: scary thought
15:44 paul   (because hdl & me are in a LAN, so sharing a directory is not a good solution : would be too hard for him when my computer off, or ADSL out...)
15:45 slef   paul: if you both have ssh access to a server, using ssh rather than a git server may be easier.
15:46 kados  paul: you'd have to ask chris, he's the one who set up git.koha.org and LL's internal one
15:46 paul   slef : continue, as we both have an ssh access to other one domputer (and a VPN)
15:47 paul   (hdl can even print on my local color laserjet... fun, but we still haven't tried)
15:48 slef   I think I just had to remember to git update-server-info before each rsync (this is done by script usually)
15:54 hdl    ho
15:55 hdl    hi even
15:57 kados  hey hdl
16:00 kados  so about 4 minutes until the meeting?
16:02 slef   cool
16:05 kados  OK, almost ready to get started here
16:05 kados  http://wiki.koha.org/doku.php?id=meetingnotes07aug31
16:06 kados  so first off, who's present?
16:06 ryan   hi #koha
16:06 kados  roll call
16:07 slef   MJ Ray
16:07 kados  ok, great, and I think hdl too, eh?
16:07 kados  so here's our agenda:
16:07 kados  http://wiki.koha.org/doku.php?id=meetingnotes07aug31
16:07 kados  anything we need to add?
16:07 hdl    yep
16:08 kados  if you have something to add, interupt me
16:08 kados  lets start with Database Design (10 minutes)
16:08 kados  MJ, you wanna explain the first item?
16:08 slef   http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1386
16:09 slef   erm, is that the right bug number?
16:09 kados  huh
16:09 kados  doesn't look like it
16:09 slef   http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1368
16:09 slef   so I knew which two numbers were most likely transposed ;-)
16:10 kados  heh
16:10 kados  ok, so how can we avoid the FOREIGN KEY violations?
16:10 slef   Right, in short, I think mysqldump's are consistent
16:11 slef   so they load the table used as the key before the tabling using the key
16:11 kados  right
16:11 slef   but we need to define the dependencies between the other .sql files somehow
16:11 kados  well one thing I think I noticed
16:11 kados  we have kohastructure.sql
16:11 slef   myself, I use Make as a sledgehammer for these things, but maybe there's a perl way
16:11 kados  that has defs
16:12 kados  and then the marc framework.sql that has a slightly different def
16:12 kados  unless I'm mistaken
16:12 slef   as in CREATE TABLEs?
16:12 kados  yea
16:12 ryan   turn off checking, i say
16:12 hdl    Why would marc_framework create tables?
16:12 slef   ryan: -1
16:13 kados  OK, sorry, I'm wrong
16:13 hdl    IMHO, marc or sql datas should be only for data inserts.
16:13 slef   hdl: web installer only INSERTs?
16:13 kados  thd's frameworks have CREATE table
16:13 kados  but the default don't
16:13 kados  so that's fine
16:13 kados  we store CREATE TABLE in kohastructure
16:13 hdl    installer should do updatedatabase which could update db structure.
16:13 kados  hdl: right
16:14 hdl    But step 3 should be data inserts only
16:14 hdl    again, imho
16:14 kados  for a new installation, I don't think we should use updatedatabase
16:14 slef   I want updatedatabase to go away, except for 2.2->3.0 upgrades, perhaps.
16:14 kados  yep, me too
16:14 hdl    I think we need both.
16:14 slef   I thought paul emailed about that recently?
16:14 paul   updatedatabase to go away ???
16:15 paul   you mean remove & discard it ?
16:15 hdl    One migration script from 22 to 3
16:15 hdl    and one update database between minor 3.0 versions.
16:15 hdl    what paul said in his db structure email made perfect sense to me.
16:15 hdl    kohastructure.sql
16:16 slef   hdl: http://lists.gnu.org/archive/html/koha-devel/2007-08/msg00055.html ?
16:16 hdl    yep
16:16 slef   paul: only use it for 2.2.x to 3.0, do 3.0.x to 3.y.z steps in SQL
16:17 hdl    in separate sqlfiles you mean ?
16:17 kados  I think separate sql files is the way to go
16:17 paul   in updatedatabase (new version), there is only SQL statements + what is needed to update the KOHAVERSION stuff.
16:17 kados  for instance, we could have a sql file for sysprefs
16:17 slef   hdl: yes
16:17 kados  simple to update, read, etc.
16:18 kados  what I'd like to propose, is a single place for the database structure to be stored
16:18 slef   hdl: so it would be mostly ALTERs, UPDATEs and maybe SELECT INTOs
16:18 kados  and a set of sql files that store default values for various modules of KOha
16:19 paul   slef : how will you apply them ?
16:19 slef   hdl: and the web installer could load these on upgrade, couldn't it?
16:19 slef   paul: ^^
16:19 hdl    (paul : installer would)
16:19 hdl    But then would come the problem of managing versions and files.
16:19 paul   so, there's almost no differences with actual updatedatabase, except that all SQL files are stored in updatedatabase, and you propose to load each SQL file separatly.
16:20 slef   (By the way: on other points in this section of the agenda, I either agree or have no view.)
16:20 hdl    would it again be a directory based version management ?
16:20 paul   through a new-still-to-write script during update
16:20 kados  ok, hang on
16:20 kados  lets get to the agenda
16:20 kados  first is design
16:20 kados  have we resolved the FOREIGN KEY question?
16:21 kados  what is the solution there?
16:21 slef   for http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1368#c4 ?
16:21 paul   if the datas are loaded carefully (parent before child), it is solved imho
16:21 paul   otherwise FOREIGN_KEYS=0
16:22 kados  given that the installer can't order them properly, we should stick with FOREIGN__KEYS=0?
16:22 slef   so in normal installer operation, it must work that 01_* is loaded before 02_* or similar?
16:22 slef   why can't the installer call sort() on the file list?
16:22 kados  slef: that was my original plan, but it doesn't work that way now
16:23 kados  because the list is passed to several hashes along the way
16:23 hdl    how is it sourced then ?
16:23 slef   hdl: how does the web installer order the files to load?
16:23 kados  and I couldn't find a way to sort it
16:23 kados  and I'm not sure I like the naming convention of 01_ 02_ etc.
16:24 kados  because you might end up having to re-order and that'd be a pain
16:24 paul   kados ++
16:24 slef   back to needing to define deps and solve the ordering problem...
16:24 slef   how should we define dependencies between the SQL files?
16:25 slef   "requires" comments at the start of the SQL files?  A dependencies.pl file?
16:25 slef   dependencies.pl is probably simplest to load, I guess
16:25 kados  hmmm, so what's this now?
16:26 kados  define deps? for sql?
16:26 slef   yeah, to say "this file must be loaded after those"
16:26 kados  ahh
16:26 slef   which is what I think paul is saying the solution is
16:26 slef   to load parents before children
16:26 kados  yes, that's the solution, clearly
16:26 kados  but as I said, I coudln't figure out how to do it
16:26 hdl    it would be a text file
16:26 hdl    with :
16:27 hdl    entryon:dep1,dep2,dep3
16:27 hdl    entry2:dep2.1,dep2.2
16:27 hdl    entry3:
16:27 paul   mmm... isn't it a little bit hard & complex, where FK=0 could do the job ?
16:27 slef   paul: if you FK=0 then you may get a broken db at the end of the install and not know
16:28 kados  yea, that's I think the point
16:28 kados  and I agree, we should do it right from the start
16:28 paul   mmm... right...
16:28 kados  slef: what would dependencies.pl do?
16:29 slef   kados: probably a hash of 'filename.sql' => ['parent1.sql',...]
16:29 slef   no functional difference to hdl's format, really
16:29 kados  k
16:29 ryan    is it not also possible to have valid constraints that form a loop, so you can't fix it by ordering
16:29 hdl    to be stored in a file.
16:29 slef   I just thought it might be easier to load
16:29 kados  so I guess we agree on how to do it, the question is, who?
16:29 slef   ryan: yes, you need cycle detection.
16:30 kados  any volunteers to add this feature?
16:30 slef   kados: let's summarise this into kohabug 1368 after the meeting and call for help on koha-devel, then pressure someone into it next meeting?
16:30 kados  slef: ok, fair enough
16:31 kados  I'll take that action
16:31 slef   I can see how to do it by calling Make... not sure how to do it in perl... I guess there's a CPAN module for solving dependency graphs
16:31 kados  OK, lets move on to the fun stuff
16:31 kados  :-)
16:31 slef   If I do it by calling Make, I expect I'd upset the win32 people
16:31 kados  ahh, right
16:31 kados  so the other issues raised in the Design section
16:32 kados  anyone have thoughts / complaints . etc>
16:32 slef   do we need to remove SQL92 keywords if we quote them properly?
16:32 slef   we should quote field names anyway, else new mysql keywords bite us
16:33 slef   (everyone remember the "return" problem?)
16:33 kados  well, I'm just passing on what I've received in feedback from others
16:33 slef   who?
16:33 kados  specifically, one vocal db designer named Dan Scott
16:34 kados  these are his recommendations to improve portability of Koha's SQL
16:34 slef   Oh yes.  I commented in http://lists.gnu.org/archive/html/koha-devel/2007-05/msg00008.html
16:35 paul   I've no objections. once we have removed all mySQL specific queries, we should be DB agnostic
16:35 kados  right
16:35 kados  OK, then I will add these as guidelines in our coding practices
16:36 slef   do we need to remove SQL92 keywords if we quote them properly?
16:36 kados  I don't know the answer to that
16:36 slef   so don't add that one as a coding guideline until we do?
16:36 hdl    (once we have removed all mySQL specific queries : hard task.)
16:36 kados  slef: ok
16:36 slef   else we're possibly solving the wrong problem
16:36 ryan   i think it makes sense to not use any more of them...
16:36 ryan   (as a guideline)
16:36 slef   ryan: +1
16:36 kados  ryan: *nod*
16:37 slef   hdl++
16:37 kados  ok, well unless any other things in section one we can move on
16:37 kados  we're a bit behind schedule :-)
16:37 slef   nothing
16:37 kados  Database Maintenance ( 10 minutes )
16:37 slef   we've covered a bit of this
16:37 kados  right
16:38 paul   although we don't have taken a decision yet...
16:38 kados  right
16:38 kados  ok, so we all agree that kohastructure.sql should be the authoritative place for new installs
16:38 slef   +1
16:38 kados  the koha db defs
16:39 paul   kados : we don't agree completly...
16:39 kados  for _new_ installs
16:39 paul   we need a single authoritative place.
16:39 kados  ie, install koha for the first time
16:39 paul   and it has to deal with install AND updates
16:39 kados  why?
16:39 paul   let me explain :
16:40 paul   NPL has version X.Y.Z.T
16:40 paul   version X.Y.Z+1 is released :
16:40 paul   NPL needs a way to update it's database
16:40 kados  yep
16:40 kados  ok, that I understand
16:40 paul   TPL installs Koha for the 1st time
16:40 kados  i thought you were saying a new install needs to update too
16:40 kados  but you're not, right?
16:40 paul   X.Y.Z+1,T
16:41 paul   they need to get a fresh uptodate DB.
16:41 paul   if wee consider that we have only 1 place to define the DB
16:41 paul   then we need to have 3.0.0.0.0 in kohastructure.sql
16:42 paul   and all steps (until 4.0.0.0) in a separater file
16:42 kados  ?
16:42 kados  ahh
16:42 slef   one file to define, N files for updates
16:42 kados  I think every release of Koha should have kohastructure.sql accurate for that release
16:42 paul   it means you have 2 places where your DB is defined.
16:42 paul   you will be de-synched soon or later
16:43 kados  hmm
16:43 paul   I think every *MAJOR* release of Koha should have kohastructure.sql accurate for that release
16:43 paul   for a minor release, the authoritative must be a separate file I think
16:44 slef   I don't mind either plan, but it will mean each 3.x minor becomes slower to install than the previous
16:44 kados  why can't we have, as a requirement before minor release, creation of an update sql from previous release?
16:44 kados  personally I don't want to have db defs scattered in multiple files
16:44 ryan   i prefer always knowing that kohastructure accurately defines the db.
16:44 kados  it's too hard to read
16:45 paul   with kohastructure.sql + updatedatabase as defined atm, I think it's much more easy to read than a single file
16:45 paul   because if a customer has a problem, you can identify which step went wrong during DB update
16:45 kados  paul: can you explain?
16:46 paul   in actual updatedatabase (new version, as suggested in my today mail), all steps are clearly identified and isolateds.
16:46 paul   you know what is to do to move from 3.0.2 to 3.0.3
16:47 paul   where a single kohastructure.sql is a large file, hard to investigate.
16:47 kados  right now updatedatabase does too much IMO
16:47 kados  we need one mechanism to update the structure
16:47 kados  and another to update the content
16:47 kados  IMO
16:47 paul   i'm speaking of updatedatabase cleaned
16:47 kados  ahh
16:48 kados  http://lists.gnu.org/archive/html/koha-devel/2007-08/msg00055.html
16:48 kados  this idea?
16:48 paul   all what concern 22 -> 3.0 is removed
16:48 paul   (in a separate update22to30 script)
16:48 kados  are you addressing structure only, or content too?
16:48 kados  for instance, checking for existance of sysprefs
16:48 paul   what do you call "content" ?
16:48 paul   yes
16:49 kados  ok, I think the two should be separate
16:49 paul   or filling shelfcontents.biblionumber when it is created
16:50 paul   note that I'm sure that some of those features won't be doable with a single SQL query...
16:50 paul   we will need to do some perl to check/discard/calculat some things
16:50 paul   so I really thing my updatedatabase strategy is better
16:51 ryan   paul: are you imagining that kohastructure has insert statemnts in it?
16:51 paul   ???
16:51 ryan   it's just table defs, right?
16:51 paul   right.
16:51 kados  there are only four operations, right?
16:52 paul   ryan : so, a question : how will you handle a new systempref that appears for 3.0.2 ?
16:52 kados  INSERT, DELETE, UPDATE, ALTER ?
16:52 hdl    ryan : but updating database from 3.X.Y to 3.X.Y+1 could require to add data to some fields.
16:52 paul   hdl++
16:52 kados  hdl: of course
16:52 ryan   right, but data doens't go in kohastructure.
16:52 paul   kados : right. except the INSERT/DELETE/UPDATE/ALTER can rely on some complex calculus
16:52 hdl    not in kohastructure.
16:53 paul   that SQL can't handle
16:53 kados  what I'm proposing is that all the INSERT statements be stored in kohastructure.sql
16:53 kados  oops
16:53 hdl    But kohastructure would be authoritative for 3.0.0.0.0
16:53 ryan   kados: really?
16:53 hdl    kados ???
16:53 dewey  kados is champion alligator-wrestler in 7 counties
16:53 kados  CREATE / DROP / INSERT / DELETE / UPDATE / ALTER
16:53 slef   dewey: forget kados
16:53 dewey  slef: I forgot kados
16:53 kados  all CREATE should be in kohastructure.sql
16:53 kados  IMO
16:54 ryan   ah, yes.
16:54 ryan   ONLY CREATE.
16:54 kados  and there shoudln't be any CREATE anywhere else IMO
16:54 hdl    ALTER for foreign keys perhaps.
16:54 paul   and how will you handle a new table, or a new column appearing in 3.0.2 ?
16:54 slef   ALTER
16:54 slef   and maybe an UPDATE
16:54 kados  hdl: can be in CREATE
16:54 kados  paul: it should be added to kohastructure.sql
16:55 paul   and how will you deal with a library upgrading from 3.0 to 3.0.2 ?
16:55 kados  a changelog
16:55 paul   !!! wow !!!
16:55 slef   paul: load kohastructurechanges3.0.1.sql and kohastructurechanges3.0.2.sql ?
16:55 paul   the updatedatabase solution is MUCH more easy for the library !
16:55 hdl    kados--
16:56 kados  paul: you're missconstruing what I'm saying
16:56 kados  I'm strictly talking about the storange and maintenance of the database defs
16:56 kados  ie, where and how they are stored
16:56 kados  not whether it is automated
16:56 kados  of course it should be an automated process
16:56 paul   but if you want only 1 place to have DB definition, then you have a problem ;-)
16:57 kados  I don't think so
16:57 paul   because if you have it in kohastructure.sql, then you can't update.
16:57 paul   explain your idea then
16:57 kados  every release has a diff between the current kohastructure.sql and the previous
16:57 kados  that diff is expressed in some kind of changelog
16:58 kados  but the kohastructure.sql file is pure, it contains all that is needed for a new install
16:58 paul   who/what build that kind of change log ?
16:58 kados  the RM
16:58 paul   so there are 2 places to define the database ;-)
16:58 kados  it's one of the last steps before releasing
16:58 kados  nope
16:58 hdl    this kind of changelog would result in an sql file ?
16:58 kados  only one
16:59 kados  there is one place to define the db, and one place to define changes from the previous one
16:59 kados  this is strictly for the db structure
16:59 kados  we also need to handle changes to the data
16:59 kados  ie, sysprefs change names, or new sysprefs, etc.
17:00 paul   right. And that's also why I think it would be better to have only 1 place for all of this, and I think it's updatedatabase...
17:00 slef   updatedatabase is a rat's nest at the mo, isn't it?
17:00 paul   slef : in simple english, what does it mean ?
17:00 paul   ;-)
17:00 kados  rats nest == a mess :-)
17:01 slef   paul: unstructured
17:01 paul   right, but with the cleaned version, it will be only a few lines long
17:01 paul   remember that 95% of the lines can be removed
17:01 paul   (all the one that rely with 22 -> 30 update)
17:02 slef   95% of the lines look like stuff that can be done with SQL, so far as I can see so far
17:02 kados  everything to do with the structure can be done in SQL
17:02 slef   check if this exists/doesn't exist and delete it/create it, sort of thing
17:02 paul   slef : the cleaned updatedatabase removes lines from 49 to 2099
17:02 paul   slef : that will be removed !
17:03 slef   Is this the hard bit?
17:03 kados  if everything to do with structure can be done in SQL, why not store it in a SQL file?
17:04 slef   ah, from 3.00.00.001 on
17:04 slef   by the way, perl version would be 3.00.00_001 apparently (but I can't remember where I saw that)
17:04 slef   developer releases have an underscore in them
17:05 kados  fair enough
17:06 slef   only unusual thing so far is DropAllForeignKeys?
17:06 kados  slef: what do you mean by unusual?
17:07 slef   as in "not simple SQL"
17:07 paul   atm, yes.
17:07 paul   but I bet what you want that one day or another, we won't be able to handle an upgrade with SQL only.
17:08 hdl    For instance, between reserves for items and reserves for biblios or else...
17:08 kados  the big problem with a massive script like updatedatabase is that a programmer shouldn't have to understand how it works to work on Koha
17:08 kados  IMO
17:08 slef   maybe not, but using perl to calculate should be a special case - it means we've fundamentally changed the DB design in one aspect
17:09 paul   kados : 99.5% of the script will be discarded
17:09 paul   and we all agree that it has become too fat
17:09 paul   the new structure solves the problem
17:09 paul   as every step is clearly isolated from the other
17:09 paul   (with the KOHAVERSION checking)
17:09 slef   using perl for simple updates is using a swiss army chainsaw to crack a nut
17:10 hdl    (anyway web installer is a perl script)
17:10 hdl    (and updating would be done via webinstaller)
17:10 slef   if it's broken down step-wise, then either it's going to be very SQL-like, or there will be lots of helper functions and updatedatabase will slowly become itself again
17:11 paul   the update is automatic, it reports what it does in english
17:11 paul   it is (very) easy to track for developpers
17:11 slef   no l10n?
17:11 kados  I don't think a developer should have to understand updatedatabse to work on Koha
17:11 hdl    He wont.
17:11 paul   kados ++ : and with the actual solution he does not need !
17:12 hdl    The latest updatedatabase was done via webinstaller.
17:12 hdl    (for me)
17:12 paul   if I add a new parameter, you will automatically be redirected to the update page, and it is done
17:12 paul   (once my commit is validated)
17:12 kados  I will re-read
17:12 paul   you (developper) don't need to know exactly what it does. it just does it !
17:12 slef   hdl: is there any difference to user between webinstaller running updatedatabase and webinstaller loading sql update file(s)
17:13 hdl    atm, no.
17:13 hdl    But my bet is that when adding new features, there will.
17:13 slef   so both are equally friendly!
17:13 hdl    new features => new fields
17:14 slef   DropAllForeignKeys is the sort of thing to avoid.  We should know what foreign keys are there and ALTER TABLE ... DROP FOREIGN KEY ... on them.
17:14 hdl    new fields that needs some updating for production system
17:14 hdl    for instance my publication date in rel228 added to serials
17:15 slef   kados: jump to end of file, read DropAllForeignKeys and see if you are scared yet.
17:15 paul   slef : except that you can have a new field, or a new systempref, or some calculus to do, and you'll finish with some values in SQL, some things in perl, ... harder to track.
17:15 kados  paul a developer needs to update the sql def sometimes
17:15 kados  he shouldn't have to kunderstand updatedatabase to do that
17:15 slef   hdl: ALTER TABLE ... UPDATE ...
17:15 paul   slef : the wrong thing with mySQL is that he can't report correctly foreign keys
17:15 paul   so you need to to that dirty thing I did
17:16 paul   kados : right. And with the new updatedatabase, he don't need
17:16 slef   paul: but we know what foreign keys exist!  we can DROP them by name!
17:17 slef   if some third-party developer has added a foreign key, he is going to get annoyed if we interfere with it like that!
17:17 paul   remember that updatedatabase cleaned starts at line 2107
17:17 kados  I still don't see why we need to store SQL in updatedatabase
17:18 paul   because you want them in 1 place only.
17:18 kados  so far everything I see related to the structure could be acomplished with a sql file
17:18 slef   paul: DropAllForeignKeys is after 2107
17:18 kados  yikes!
17:18 kados  DropAllForeignKeys?
17:18 dewey  i guess DropAllForeignKeys is the sort of thing to avoid.  We should know what foreign keys are there and ALTER TABLE ... DROP FOREIGN KEY ... on them.
17:18 paul   right, but if you have another solution, i take it !
17:18 slef   paul: see dewey
17:19 ryan   as hdl says, sometime you might add a column to a table, but with live data, that column's values will be dependent on another column...
17:19 slef   ryan: UPDATE table SET column = function(other_column);
17:19 kados  ryan: yes, and I still haven't seen a case where that can't be managed in a SQL statement
17:19 paul   slef : i've seen your "drop them by name", but for a reason I don't remember, it was not possible.
17:20 paul   slef : the function maybe too complex for mySQL...
17:20 ryan   sql functions are quite limited.
17:20 slef   paul: when you remember, I'll stop objecting.
17:20 paul   slef : OK, will try to remember then ;-)
17:21 hdl    when you have a clear way to manage updates, we'll stop argue.
17:21 paul   7:30PM here, Sandrine waiting for me & childs very tireds...
17:22 hdl    until now, the "changelog" does not convince me for long run management.
17:22 hdl    But I may be misunderstanding.
17:23 hdl    (And i am not the only one)
17:24 hdl    It is not that we are stubborn and we donot want to evolve to what you propose.
17:24 kados  I have two primary concerns:
17:24 slef   ryan: indeed.  Maybe we'll over step them one day, but I'm surprised it happened in the first DB update.
17:25 kados  1. developers need one simple place to make db changes when they add a new feature
17:25 hdl    slef : we have to think for long term.
17:25 kados  2. we need to enforce careful db maintenance from version to version
17:26 kados  I really want to avoid automating tasks that shouldn't be automated (I'm speaking of DB maintenance for development, not client updates)
17:26 slef   hdl: yes, and having a turing-complete database definition is not a long-term solution.
17:26 hdl    (turing-complete ???)
17:26 kados  I think there's a role for a perl script to be involved in updates
17:27 kados  but any SQL that the script calls should be stored in a sql file
17:27 slef   hdl: essentially, something that you have to execute (or pseudo-execute) to see what it does
17:27 paul   kados : /me could be ok with this idea
17:27 kados  as a developer, I shouldn't have to add something to updatedatabase to get my change in the next release
17:28 paul   why ? if it's simple & clear to do ?
17:28 kados  and as a user, the db definition in kohastructure.sql should be complete
17:28 paul   more than this : when I add something, the FIRST thing I do is to define the table in updatedatabase
17:28 kados  paul: updatedatabase has promoted poor coding pratices
17:28 kados  paul: so I want it to die :-)
17:29 paul   the old version is dead. we agree
17:29 hdl    But only updating kohastructure.sql
17:29 paul   the new version is really different.
17:29 kados  paul: you say that, but pratice shows that it has had many problems
17:29 kados  stretching back to 2.0
17:29 hdl    made me lost for updating my kohastructure, by ha,d.
17:29 hdl    made me lost for updating my kohastructure, by hand.
17:29 kados  and we can also prove right now that your structure is very different than kohastructure.sql
17:29 hdl    And it was a real pain.
17:29 slef   paul: OK, can you post the reason for DropAllForeignKeys to koha-devel next week, please?
17:29 hdl    I assure you.
17:29 paul   slef : ok, if I remember
17:30 kados  ie, if you dump san and ipt, it will be different than kohastructure.sql in git
17:30 kados  hdl: it si a pain, but a necessary one
17:30 slef   hdl: "made me lost" doesn't make sense
17:30 kados  hdl: IMO
17:30 hdl    slef : broke my stuf when synching.
17:30 hdl    (CGI::Session for instance.)
17:31 kados  hdl: right
17:31 hdl    (virtualshelves...)
17:31 kados  I'm not suggesting we don't have a mechanism in place for updating sql between versions
17:31 kados  what I am suggesting is that the mechanism not be a perl script
17:31 kados  I'm suggesting that it be a sql file or files
17:31 kados  and that we distinguish between updating definitions and updating content
17:32 paul   kados : it will be harder to maintain on the long term. And more complex for a developper to decide where to put a change.
17:32 hdl    (That would lead to not only one authoritave sql file....)
17:32 paul   + I still bet that one day we won't be able to do what we want just with SQL
17:32 kados  paul: there is only one place for a developer to put a change
17:33 slef   paul: the updatedatabase has been harder for everyone except your firm to maintain, as far as I can tell
17:33 paul   slef : I agree it was a nightmare (and it was not my creation 1st...)
17:34 paul   with the cleaned version, it will be zillions of times easier to follow
17:34 slef   paul: and if we need to resort to perl one day, then we can, but 99% of updates won't
17:34 hdl    kados, slef : are you proposing to have multiple sql files to manage db changes between minor versions ?
17:34 slef   More developers understand SQL defining and altering databases than understand perl calculations
17:34 kados  hdl: yes
17:34 slef   hdl: no opinion
17:34 kados  hdl: and only the RM needs to create that
17:35 hdl    Don't you think it would end up in a messy crowdy directory ?
17:35 paul   ok, I think I can live with a sql file for each update. Even if I think it's not the best solution.
17:36 slef   hdl: better that than a messy crowdy script, no?
17:36 kados  and, it requires the programmer to 'guess' abotu what version their code will appear in
17:36 kados  that's the RM's choice IOM
17:36 kados  IMO even
17:36 kados  we don't want programmers submitting patches with version numbers in them
17:36 hdl    you're the RM.
17:36 kados  assuming that their code will be in the next version
17:36 paul   mmm... good point to kados
17:36 slef   kados: oh, I understand, finally.
17:37 paul   but that will solve only a part of the problem : I want to add a column, or a table. What do I do exactly ?
17:37 hdl    update kohastructure.sql ?
17:37 kados  paul: add it to kohastructure.sql and submit a patch
17:37 paul   then what do you do with the patch ?
17:37 slef   send it to QA, patches@koha
17:37 kados  the RM chooses to apply or not
17:38 kados  along with the code submission
17:38 paul   of course, but I wanted to know what do you do if you devide to apply it ;-)
17:38 paul   (decide even ;-) )
17:38 hdl    When RM receives the patch, he would have to both take it and create the sql patch.
17:38 kados  yep
17:38 kados  RM accepts and creates/updates update.sql
17:39 paul   and how are other developpers informed that there is something to update in their DB ?
17:39 kados  so all the developer needs to do is update kohastructure.sql with his code submission
17:39 hdl    version_xupdate.sql
17:39 kados  hdl: exactly
17:39 slef   paul: you see update.sql appear when you pull
17:39 hdl    (for filename would be better)
17:39 kados  it's all stored in a changelog
17:39 slef   (or update)
17:39 kados  called version_x_update.sql
17:39 hdl    with x the number of the change.
17:39 kados  or something like it
17:40 paul   but /me think he won't convince you...
17:40 kados  it is more time consuming for the RM for sure
17:40 slef   that's because your solution is yours
17:40 kados  but it enforces better coding practices
17:40 kados  and more careful sql updates
17:40 paul   slef : nope, I don't think so.
17:41 kados  and is easier on developers IMO
17:41 hdl    (No, that is because experience with kohastructure.sql was quite painfull)
17:41 paul   kados : the actual solution (with updatedatabase cleaned) is signthly the same from a RM / QA / git pov
17:42 kados  how so?
17:42 kados  signthly?
17:42 paul   sightly, sorry
17:42 kados  well maybe I don't understand it properly
17:42 kados  what I don't like is that it has sql in a perl script
17:43 kados  it has changes linked to a version string also in a perl script
17:43 kados  it requires developers to understand the functioning of a perl script to add db changes
17:43 paul   kados : if a developer can't handle that, I doubt it will be a usefull Koha developper :-D
17:43 hdl    (without perl skills, you cannot program for Koha modules)
17:44 kados  perhaps we can come up with a hybrid mechanism for updating versions
17:44 kados  it's not about perl skills
17:44 kados  it's about having to read someone else's code to get your own committed, even for minor changes
17:45 kados  and it encourages updatedatabase to grow like it did last time
17:45 kados  which I really want to avoid
17:45 hdl    (once you have read it twice, you know... the mechanism).
17:45 slef   Understanding updatedatabase as an entry test for koha-devel?  Ow.
17:45 kados  heh
17:45 paul   kados : updatedatabase contains everything since 1.2 iirc. that's why it became huge
17:45 hdl    But, once again, you are the RM.
17:45 kados  hdl: read what twice?
17:46 kados  updatedatabase?
17:46 dewey  updatedatabase is a rat's nest at the mo, isn't it?
17:46 kados  hehe
17:46 paul   and the idea of checking everything to see if it has to be applied is poor to.
17:46 kados  ok, I guess we need to have another discussion to settle this
17:46 kados  or take it to koha-devel
17:46 paul   ok, at your preference.
17:47 kados  I'll try to summarize the differences on koha-devel later today
17:47 paul   i'm available everyday in the next 2 weeks (except sep,7)
17:47 kados  without too much bias I hope :-)
17:47 paul   great. bye then
17:48 hdl    kados: read updatedatabase (or print)
17:49 kados  hdl: yep, I have
17:50 hdl    I wanted to say that when you read and updated updatedatabase once or more, you can handle the burden to modify it for each change in db you want to make.
17:50 hdl    Sorry for I have to leave now.
17:50 kados  ok, have a nice time with your parents
19:44 libtux hi..can i know How do I upgrade perl version 2.1.8 to Perl 2.1.50?
19:46 dbs    Hah! Just saw the comment about the "vocal db designer Dan Scott" :)
19:57 kados  dbs: :-)
19:57 kados  dbs: it was a complement :-)
20:04 dbs    and it was taken as such -- no worries
20:07 kados  dbs: feel free to weigh in on any of the points covered in today's meeting
20:12 dbs    I was "Mr. DSpace" today; I'll try to catch up though