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