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