FreeNode names: rangi ru55el [K] koha← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| 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 | You can get a test or have someone on it. | |
| 12:38 | There are still <p>s and some other stuff to change. | |
| 12:38 | But it seems to work. | |
| 12:54 | only one template. | |
| 12:54 | With tabs. | |
| 12:55 | We could add a syspref for quick member entry and make a selection : firstname/surname/cardnumber/catcode/branch/phone/email | |
| 12:55 | only | |
| 12:56 | But. would endup in having two ways to enter/process data... I donot favour that. | |
| 14:56 | root | |
| 15:01 | paul | owen around ? |
| 15:27 | kados | paul: responding to your email now |
| 15:27 | 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 | 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 | paul: we can discuss that | |
| 15:33 | paul: it's not in my email | |
| 15:33 | yes, the stylesheet changes aren't complete | |
| 15:34 | but we are working rapidly on them | |
| 15:34 | and should have a description of the changes ready on Wed | |
| 15:34 | we're also writing a template style guide | |
| 15:34 | 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 | when we're done you can apply the drupal theme again quite easily | |
| 15:35 | (but I think the new default will be much prettier) | |
| 15:35 | paul | your mail seems to have been lost... |
| 15:35 | or arrives by boat maybe ;-) | |
| 15:35 | gotcha | |
| 15:36 | kados | paul: get the email yet? |
| 15:36 | paul | yep |
| 15:36 | kados | cool |
| 15:38 | slef | /names |
| 15:38 | [K] | *** #kohaFreeNode names: rangi ru55el [K] |
| 15:38 | slef | hi all |
| 15:38 | paul | hello slef |
| 15:38 | kados | hey sle |
| 15:38 | 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 | our next 2 steps are : | |
| 15:41 | - investigate cherry picking, to apply official patches when we want | |
| 15:42 | - 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 | (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 | hi even | |
| 15:57 | kados | hey hdl |
| 16:00 | so about 4 minutes until the meeting? | |
| 16:02 | slef | cool |
| 16:05 | kados | OK, almost ready to get started here |
| 16:05 | http://wiki.koha.org/doku.php?[…]etingnotes07aug31 | |
| 16:06 | 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 | so here's our agenda: | |
| 16:07 | http://wiki.koha.org/doku.php?[…]etingnotes07aug31 | |
| 16:07 | anything we need to add? | |
| 16:07 | hdl | yep |
| 16:08 | kados | if you have something to add, interupt me |
| 16:08 | lets start with Database Design (10 minutes) | |
| 16:08 | MJ, you wanna explain the first item? | |
| 16:08 | slef | http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=1386 |
| 16:09 | erm, is that the right bug number? | |
| 16:09 | kados | huh |
| 16:09 | doesn't look like it | |
| 16:09 | slef | http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=1368 |
| 16:09 | so I knew which two numbers were most likely transposed ;-) | |
| 16:10 | kados | heh |
| 16:10 | ok, so how can we avoid the FOREIGN KEY violations? | |
| 16:10 | slef | Right, in short, I think mysqldump's are consistent |
| 16:11 | 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 | 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 | and then the marc framework.sql that has a slightly different def | |
| 16:12 | 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 | but the default don't | |
| 16:13 | so that's fine | |
| 16:13 | 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 | 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 | you mean remove & discard it ? | |
| 16:15 | hdl | One migration script from 22 to 3 |
| 16:15 | and one update database between minor 3.0 versions. | |
| 16:15 | what paul said in his db structure email made perfect sense to me. | |
| 16:15 | 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 | 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 | paul: ^^ | |
| 16:19 | hdl | (paul : installer would) |
| 16:19 | 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 | lets get to the agenda | |
| 16:20 | first is design | |
| 16:20 | have we resolved the FOREIGN KEY question? | |
| 16:21 | 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 | 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 | 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 | 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 | and I'm not sure I like the naming convention of 01_ 02_ etc. | |
| 16:24 | 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 | how should we define dependencies between the SQL files? | |
| 16:25 | "requires" comments at the start of the SQL files? A dependencies.pl file? | |
| 16:25 | dependencies.pl is probably simplest to load, I guess | |
| 16:25 | kados | hmmm, so what's this now? |
| 16:26 | 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 | to load parents before children | |
| 16:26 | kados | yes, that's the solution, clearly |
| 16:26 | but as I said, I coudln't figure out how to do it | |
| 16:26 | hdl | it would be a text file |
| 16:26 | with : | |
| 16:27 | entryon:dep1,dep2,dep3 | |
| 16:27 | entry2:dep2.1,dep2.2 | |
| 16:27 | 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 | 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 | 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 | 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 | :-) | |
| 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 | so the other issues raised in the Design section | |
| 16:32 | anyone have thoughts / complaints . etc> | |
| 16:32 | slef | do we need to remove SQL92 keywords if we quote them properly? |
| 16:32 | we should quote field names anyway, else new mysql keywords bite us | |
| 16:33 | (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 | 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 | 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 | (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 | 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 | 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 | NPL has version X.Y.Z.T | |
| 16:40 | version X.Y.Z+1 is released : | |
| 16:40 | NPL needs a way to update it's database | |
| 16:40 | kados | yep |
| 16:40 | 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 | but you're not, right? | |
| 16:40 | paul | X.Y.Z+1,T |
| 16:41 | they need to get a fresh uptodate DB. | |
| 16:41 | if wee consider that we have only 1 place to define the DB | |
| 16:41 | then we need to have 3.0.0.0.0 in kohastructure.sql | |
| 16:42 | and all steps (until 4.0.0.0) in a separater file | |
| 16:42 | kados | ? |
| 16:42 | 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 | 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 | 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 | 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 | 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 | you know what is to do to move from 3.0.2 to 3.0.3 | |
| 16:47 | where a single kohastructure.sql is a large file, hard to investigate. | |
| 16:47 | kados | right now updatedatabase does too much IMO |
| 16:47 | we need one mechanism to update the structure | |
| 16:47 | and another to update the content | |
| 16:47 | IMO | |
| 16:47 | paul | i'm speaking of updatedatabase cleaned |
| 16:47 | kados | ahh |
| 16:48 | http://lists.gnu.org/archive/h[…]-08/msg00055.html | |
| 16:48 | this idea? | |
| 16:48 | paul | all what concern 22 -> 3.0 is removed |
| 16:48 | (in a separate update22to30 script) | |
| 16:48 | kados | are you addressing structure only, or content too? |
| 16:48 | for instance, checking for existance of sysprefs | |
| 16:48 | paul | what do you call "content" ? |
| 16:48 | 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 | note that I'm sure that some of those features won't be doable with a single SQL query... | |
| 16:50 | we will need to do some perl to check/discard/calculat some things | |
| 16:50 | 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 | 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 | IMO | |
| 16:54 | ryan | ah, yes. |
| 16:54 | 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 | and maybe an UPDATE | |
| 16:54 | kados | hdl: can be in CREATE |
| 16:54 | 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 | I'm strictly talking about the storange and maintenance of the database defs | |
| 16:56 | ie, where and how they are stored | |
| 16:56 | not whether it is automated | |
| 16:56 | 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 | explain your idea then | |
| 16:57 | kados | every release has a diff between the current kohastructure.sql and the previous |
| 16:57 | that diff is expressed in some kind of changelog | |
| 16:58 | 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 | nope | |
| 16:58 | hdl | this kind of changelog would result in an sql file ? |
| 16:58 | kados | only one |
| 16:59 | there is one place to define the db, and one place to define changes from the previous one | |
| 16:59 | this is strictly for the db structure | |
| 16:59 | we also need to handle changes to the data | |
| 16:59 | 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 | ;-) | |
| 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 | remember that 95% of the lines can be removed | |
| 17:01 | (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 | 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 | by the way, perl version would be 3.00.00_001 apparently (but I can't remember where I saw that) | |
| 17:04 | 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 | 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 | 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 | and we all agree that it has become too fat | |
| 17:09 | the new structure solves the problem | |
| 17:09 | as every step is clearly isolated from the other | |
| 17:09 | (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 | (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 | 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 | (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 | (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 | 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 | 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 | 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 | so you need to to that dirty thing I did | |
| 17:16 | 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 | 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 | 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 | 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 | But I may be misunderstanding. | |
| 17:23 | (And i am not the only one) | |
| 17:24 | 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 | 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 | 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 | 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 | stretching back to 2.0 | |
| 17:29 | hdl | made me lost for updating my kohastructure, by ha,d. |
| 17:29 | 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 | 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 | (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 | what I am suggesting is that the mechanism not be a perl script | |
| 17:31 | I'm suggesting that it be a sql file or files | |
| 17:31 | 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 | 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 | that's the RM's choice IOM | |
| 17:36 | IMO even | |
| 17:36 | 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, patcheskoha |
| 17:37 | kados | the RM chooses to apply or not |
| 17:38 | 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 | (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 | 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 | 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 | signthly? | |
| 17:42 | paul | sightly, sorry |
| 17:42 | kados | well maybe I don't understand it properly |
| 17:42 | what I don't like is that it has sql in a perl script | |
| 17:43 | it has changes linked to a version string also in a perl script | |
| 17:43 | 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 | it's not about perl skills | |
| 17:44 | it's about having to read someone else's code to get your own committed, even for minor changes | |
| 17:45 | and it encourages updatedatabase to grow like it did last time | |
| 17:45 | 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 | 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 | 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 | 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 | 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 |
← Previous day | Today | Next day → | Search | Index
