IRC log for #koha, 2007-11-17

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
13:00 fbcit hello koha.
13:01 paul 'morning fbcit
13:04 kados morning #koha
13:04 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 )
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 author search don't work any more...
13:18 kados :
13:18 http://o11.bureau.paulpoulain.[…]ha/opac-search.pl
13:19 search "perles" as kw => 236 results
13:19 as author => 236 results as well, which is wrong
13:19 ccl=au=perles => 124 results, which is correct
13:20 kados I haven't looked at opac-search.pl yet
13:20 but I know many things have been changed from dev_week
13:21 paul kados : same thing on opac & staff
13:21 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 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 hehe
13:28 I'm just concerend about the overhead of maintaining all the sample data in two languages and two database
13:28 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 rather than storing sample data as SQL statements
13:29 store as delimited text files
13:29 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 that takes sample file descriptoin of some kind
13:31 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 which?
13:35 kados: did I submit patches to sample data?
13:35 kados Added French data to Pg dir
13:36 Modified SessionStorage pref to include Pg choice
13:36 fbcit: just those two
13:37 fbcit so "sample data" is the "optional" choices in the installer, right?
13:38 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 mandatory, optional, everything
13:39 otherwise maintenance is gonna be hard
13:39 fbcit yes
13:42 I think we can also do *some* standardization of SQL syntax as well which will reduce the maintenance load.
13:42 for starters, stripping the backtics and using double quotes around keywords used otherwise will help.
13:43 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 marc importing
15:54 [K] *** join #koha@FreeNode: darci|meeting i=plinkit@159.121.122.56
15:55 *** 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 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 has to be qualified by 'unique' or 'primary' to add the uniqueness constraint
16:23 fbcit k
16:23 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 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 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 ?
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 but there's a lot of cleanup to do
16:37 particularly since a lot of code isn't checking for errors on inserts
16:38 so checking all such constraints probably should be post-3.0
16:38 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 (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 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 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 http://git.koha.org/cgi-bin/gi[…]4e18ebef8;hb=HEAD
16:51 maybe?
16:52 fbcit let me check... but there is sql in more than just the structure...
16:53 got the rss setup.
16:54 we'll see how it goes... :-)
16:56 gmcharlt http://git.koha.org/cgi-bin/gi[…]kohastructure.sql
16:56 kados fbcit: what are the nature of your changes?
16:56 fbcit: could we just merge them into the main kohastructure.sql?
16:56 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 I failed to understand the underlying theory of updatedatabase.pl etc...
16:59 so I am backtracking and trying to get the update system ported so I can keep up better...
17:00 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 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 I think you can run both dbms in an ansi SQL only mode...
17:03 I'm not sure what kind of *difficulties* that may cause, though.
17:04 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 there is also the issue of mysql CURRENT_TIMESTAMP which requires a function in Pg to mimic it...
17:05 and enums... but the next release of Pg will support enums... it is in beta right now.
17:05 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 *shrug*
17:07 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 asap
17:07 :)
17:08 I run a pg backend. I don't want to support two dbms....
17:08 kados yep
17:08 ok, so lets add postgres to the schedule for 3.2
17:09 (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 I think ultimately we will ahve to do loads of testing if we make changes to the sql in the major modules
17:09 and that testing should be done for both dbms
17:09 (and concurrently for oracle IMO)
17:10 so immediately, what's holding us back from releaseing 3.0 is a fully-working installer
17:10 the opac templates
17:10 and a few outstanding bugs
17:10 (and a couple minor enhancements taht will be done next week)
17:10 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 install-CPAN could still be used since it runs independently and first
17:14 but the real issue is this:
17:14 do we use symlinks or scripting to setup the Marc stuff?
17:14 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 :-)
17:16 so we stick with the current implementation then
17:17 at least for now
17:18 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 other than that, it's mostly just some bugfixing that's been done
17:19 :-)
17:19 fbcit btw.. I'm in the US you know.
17:19 rather than UK...
17:20 s/notice/noticed/
17:21 kados: so you want me to slow up on Pg and concentrate on installer....
17:23 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 Does anyone know where I can find a list of possible values for the LANG env var on *nix?
20:18 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?

← Previous day | Today | Next day → | Search | Index

koha1