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 ?