FreeNode: darci|meeting i=plinkit159.121.122.56159.121.122.56← 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 #kohaFreeNode: darci|meeting i=plinkit159.121.122.56 |
| 15:55 | *** part FreeNode!#koha: darci|meeting i=plinkit159.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
