| Time |
S |
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.[…]ha/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=plinkit159.121.122.56 |
| 15:55 |
|
[K] |
*** 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 |
|
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/gi[…]4e18ebef8;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/gi[…]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? |
