IRC log for #koha, 2007-09-01

All times shown according to UTC.

Time S 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?[…]etingnotes07aug31
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?[…]etingnotes07aug31
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/b[…]w_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/b[…]w_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/h[…]-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/b[…]ug.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/h[…]-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/h[…]-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

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary