Time Nick Message 13:00 fbcit hello koha. 13:01 paul 'morning fbcit 13:04 kados morning #koha 13:04 kados paul: looking at patches now 13:05 paul hi kados 13:05 fbcit hi kados 13:09 kados about 25 patches 13:10 paul kados : is there something about opac ? (i haven't rebase since the day before owen last commit, so I have 3 or 4 days ago repo= 13:10 paul ) 13:14 kados paul: no template patches for opac 13:14 paul :( 13:14 kados :( 13:18 paul ! big bug detected just now... 13:18 paul author search don't work any more... 13:18 paul kados : 13:18 paul http://o11.bureau.paulpoulain.com/cgi-bin/koha/opac-search.pl 13:19 paul search "perles" as kw => 236 results 13:19 paul as author => 236 results as well, which is wrong 13:19 paul ccl=au=perles => 124 results, which is correct 13:20 kados I haven't looked at opac-search.pl yet 13:20 kados but I know many things have been changed from dev_week 13:21 paul kados : same thing on opac & staff 13:21 paul I think it's the updates you did on buildQuery 13:22 kados those were in reaction to other changes that had been introduced 13:23 kados but I agree, I"ll have a look today and see what's up 13:23 paul I'll investigate as well. and let you know if I understand where the pb comes from 13:28 kados fbcit: got a sec? 13:28 fbcit yep 13:28 kados any chance that Pg and mysql could share sample data? 13:28 kados hehe 13:28 kados I'm just concerend about the overhead of maintaining all the sample data in two languages and two database 13:28 kados s 13:28 fbcit I don't see why not right off. 13:28 kados and two marc formats 13:29 gmcharlt a thought about that 13:29 gmcharlt rather than storing sample data as SQL statements 13:29 gmcharlt store as delimited text files 13:29 gmcharlt and use bulk loaders to import 13:29 kados yea, that's the long-term goal 13:30 fbcit that sounds good to me 13:30 kados makes it easy to do a migration then too, just get your data in the format and wiz bang 13:30 gmcharlt and probably not too hard to write a program 13:31 gmcharlt that takes sample file descriptoin of some kind 13:31 gmcharlt and converts it to bulk loader config options for each DB 13:32 fbcit csv format is probably the most common and so makes perfect sense here 13:32 gmcharlt yep 13:33 kados :-) 13:33 fbcit I'm back several ver's on kohastructure right now.. 13:33 fbcit which? 13:35 fbcit kados: did I submit patches to sample data? 13:35 kados Added French data to Pg dir 13:36 kados Modified SessionStorage pref to include Pg choice 13:36 kados fbcit: just those two 13:37 fbcit so "sample data" is the "optional" choices in the installer, right? 13:38 fbcit of course I suppose that any records to be preloaded into the db could be kept in csv... 13:38 kados I guess my question is just broadly can we put all that data into a form that both mysql and postgres will understand 13:39 kados mandatory, optional, everything 13:39 kados otherwise maintenance is gonna be hard 13:39 fbcit yes 13:42 fbcit I think we can also do *some* standardization of SQL syntax as well which will reduce the maintenance load. 13:42 fbcit for starters, stripping the backtics and using double quotes around keywords used otherwise will help. 13:43 fbcit however, some of this should probably wait until after 3.0 is frozen and we branch off for the next ver... (imo) 13:44 kados yep 13:45 fbcit it has the potential to break quickly and often while porting on that scale.. :-( 13:45 kados yep 13:46 fbcit kados: I had to put the import thing on pause. My pg schema was too out of date. 13:46 fbcit marc importing 15:54 [K] *** join #koha@FreeNode: darci|meeting i=plinkit@159.121.122.56 15:55 [K] *** part FreeNode!#koha: darci|meeting i=plinkit@159.121.122.56 16:16 fbcit kados, gmcharlt: is branchcode alway unique? 16:17 gmcharlt branches.branchcode is a unique key -- is that what you're asking? 16:19 fbcit yep... I'm going to make it unique everywhere it occurs in the Pg sql. 16:19 fbcit ie. import_branches.branchcode, etc. 16:19 gmcharlt well, for that table it's a (not always required) FK to branches.branchcode 16:20 fbcit right, but in mysql it is set as a key... which I assume implies it is unique...?? 16:21 gmcharlt ah, not so -- just means that it has an index on it 16:22 gmcharlt has to be qualified by 'unique' or 'primary' to add the uniqueness constraint 16:23 fbcit k 16:23 fbcit I am missing the FK to branches.branchcode, though... 16:24 gmcharlt in that particular case, it's essentially a "loose" FK that's not enforced by DB but by app 16:25 gmcharlt needs to be tightened up, of course, but later 16:26 fbcit does mysql require FKs to reference fields that form unique values? 16:30 gmcharlt apparently so, but that's a non-SQL-standard extension 16:33 kados is there a way to trigger the same functionality using standard sql-92? 16:33 kados if so, i'd be happy to update the main kohastructure 16:34 gmcharlt by that you mean allow FK to non-unique key in parent table 16:34 gmcharlt ? 16:34 kados I'm just wondering if we're deviating from standard sql-92 and if we should not 16:36 gmcharlt as far as constraints are concerned, we probably should stick to SQL-92 throughout 16:37 gmcharlt but there's a lot of cleanup to do 16:37 gmcharlt particularly since a lot of code isn't checking for errors on inserts 16:38 gmcharlt so checking all such constraints probably should be post-3.0 16:38 gmcharlt except for known bugs 16:40 kados k 16:44 fbcit FWIW...pg has the same req on FKs... the referenced field must be unique or form a unique value... 16:45 gmcharlt ok -- so we'll need to make sure to not use MySQL's "improvement" 16:47 paul fbcit: if it's the case, then it's definetly a bug, as it appear silly to me to do that ! 16:47 paul (was for gmcharlt in fact ;-) ) 16:47 gmcharlt :) 16:48 fbcit kados: did you get a chance to setup that email yet? 16:49 kados fbcit: I need to ask you about that, what's the purpose of the email? 16:49 fbcit I would like to receive a copy of all patches affecting sql.... 16:50 fbcit that will ensure that I do the port immediately... 16:51 kados I'm not sure I can do that 16:51 fbcit bringing the Pg kohastructure up to date is a real pain because I failed to realize how many changes were going on... :-( 16:51 fbcit maybe we can give that one out and request those submitting patches affecting sql to cc?... 16:51 kados I wonder if you can get a feed from RSS on just the kohastructure.sql 16:51 kados http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=rss;f=installer/data/mysql/kohastructure.sql;h=739e08d402b0b238fe74057423b49e94e18ebef8;hb=HEAD 16:51 kados maybe? 16:52 fbcit let me check... but there is sql in more than just the structure... 16:53 fbcit got the rss setup. 16:54 fbcit we'll see how it goes... :-) 16:56 gmcharlt http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=rss;f=installer/data/mysql/kohastructure.sql 16:56 kados fbcit: what are the nature of your changes? 16:56 kados fbcit: could we just merge them into the main kohastructure.sql? 16:56 kados or would that preent it from working on mysql? 16:57 gmcharlt (previous link was for fbcit) 16:57 fbcit kados: the changes are nearly everything since about .009 forward... 16:58 fbcit I failed to understand the underlying theory of updatedatabase.pl etc... 16:59 fbcit so I am backtracking and trying to get the update system ported so I can keep up better... 17:00 fbcit my structure was so far out that in addition to the syntax issues, I was missing fields when working on the bulk import stuff... 17:00 kados what I'm asking is, do we need to have two kohastructure.sqls? 17:01 kados or can the modifs you've made to the pg one be ported to the mysql one 17:01 fbcit kados: I think we will always have to have two 17:02 kados is that because neither dbms can read standard sql-92? 17:02 fbcit Pg does not know about secondary keys and so you have to create additional indexes to effect the same result. 17:02 fbcit I think you can run both dbms in an ansi SQL only mode... 17:03 fbcit I'm not sure what kind of *difficulties* that may cause, though. 17:04 fbcit I started some reading on the sql standard the other day with an aim to answer these types of questions, but have not had time to pursue it. 17:04 fbcit there is also the issue of mysql CURRENT_TIMESTAMP which requires a function in Pg to mimic it... 17:05 fbcit and enums... but the next release of Pg will support enums... it is in beta right now. 17:05 fbcit presently I use CHECK constraints to mimic enums. 17:06 kados that always confuses me, seems like the postgres purists are always complaining about mysql's poor implementation of features 17:06 fbcit the mysql syntax I saw in Biblio.pm could be modified to work for both mysql and pg, but would need some testing... 17:06 kados but from what I've seen there are perhaps as many that postgres hasn't implemented 17:06 kados *shrug* 17:07 kados fbcit: what's your timeline for getting koha going with postgres? 17:07 fbcit the biggest issue I've had with mysql is the lack of a truly relational dbms.. 17:07 fbcit asap 17:07 fbcit :) 17:08 fbcit I run a pg backend. I don't want to support two dbms.... 17:08 kados yep 17:08 kados ok, so lets add postgres to the schedule for 3.2 17:09 kados (you are welcome to add/maintain stuff for 3.0 but we won't make it official) 17:09 fbcit I just spent time moving from M$SQL to pg... pg is mature and is a strong competitor with M$ feature wise 17:09 kados yep 17:09 kados I think ultimately we will ahve to do loads of testing if we make changes to the sql in the major modules 17:09 kados and that testing should be done for both dbms 17:09 kados (and concurrently for oracle IMO) 17:10 kados so immediately, what's holding us back from releaseing 3.0 is a fully-working installer 17:10 kados the opac templates 17:10 kados and a few outstanding bugs 17:10 kados (and a couple minor enhancements taht will be done next week) 17:10 kados fbcit: what did you think of mj's response regarding the isntaller? 17:11 fbcit I am familiar with LedgerSMB as we are looking at using it after it matures a bit. I am planning on asking over there what the issues were. 17:12 kados *nod* 17:13 fbcit As for installing the M::B module... most admins will already be in install mode with the MARC and other modules... 17:13 fbcit install-CPAN could still be used since it runs independently and first 17:14 fbcit but the real issue is this: 17:14 fbcit do we use symlinks or scripting to setup the Marc stuff? 17:14 fbcit if symlinks, I don't know if MakeMaker will work... 17:15 kados more I think about it I think we should avoid symlinks 17:15 fbcit if scripting, then we can probably use what we have in place with modifications 17:15 kados just because there are some popular OSes that won't support them 17:16 kados :-) 17:16 kados so we stick with the current implementation then 17:17 kados at least for now 17:18 kados was it unsafe recently? 17:18 fbcit it sounded like opac was having some trouble the other day... :-) 17:18 kados ahh, yea, there are still a couple issues with the opac 17:19 kados other than that, it's mostly just some bugfixing that's been done 17:19 kados :-) 17:19 fbcit btw.. I'm in the US you know. 17:19 fbcit rather than UK... 17:20 fbcit s/notice/noticed/ 17:21 fbcit kados: so you want me to slow up on Pg and concentrate on installer.... 17:23 fbcit brb... lunch 17:25 kados fbcit: perhaps, because if we can roll out 3.0, that will let us concentrate on doing Pg right 20:09 fbcit paul? 20:17 fbcit Does anyone know where I can find a list of possible values for the LANG env var on *nix? 20:18 fbcit specifically the language_territory section... 20:46 gmcharlt fbcit: for all that are currently installed at the OS level: locale -a 20:48 fbcit gmcharlt: actually I was looking for a list of all possible. /usr/share/i18n/locales turns up the best list so far... 20:49 gmcharlt fbcit: also see RFC 3066 for references to applicable ISO standards 20:54 fbcit gmcharlt: tnx. 03:58 thd kados: are you awake?