Maybe this is already solved but-- It seems like it would be fun if there was a nicely generic format defined for Koha data dumps. Is it correct that right now this is a DB specific task? I'm thinking some format that would be good for-- - working across different versions of Koha (within reason) - portable backups - a stable interchange format when migrating between Koha and other ILSs - the case where some library is running v2 and it's really, really finally time for them to move to v12 and they now have the resources to do it -reed
Reed Wade wrote:
It seems like it would be fun if there was a nicely generic format defined for Koha data dumps. Is it correct that right now this is a DB specific task?
This is a good idea, esp. when migrating data. Two simple, popular and powerful formats come to mind: 1. CSV, directly importable into spreadsheet and database programmes 2. XML, easily handled by MySQL, more transparent than CSV cheers rickw -- _________________________________ Rick Welykochy || Praxis Services
On Wed, Jun 02, 2010 at 12:18:50PM +1000, Rick Welykochy wrote:
1. CSV, directly importable into spreadsheet and database programmes 2. XML, easily handled by MySQL, more transparent than CSV
I would choose YAML because - it can store tree (as xml) without the need of extra tags (required in xml) - it's human readable/editable - it supports pointed structures - it's now supported everywhere HTH -- Marc Chantreux BibLibre, expert en logiciels libres pour l'info-doc http://biblibre.com
Marc Chantreux <marc.chantreux@biblibre.com>
On Wed, Jun 02, 2010 at 12:18:50PM +1000, Rick Welykochy wrote:
1. CSV, directly importable into spreadsheet and database programmes 2. XML, easily handled by MySQL, more transparent than CSV
I would choose YAML because - it can store tree (as xml) without the need of extra tags (required in xml) - it's human readable/editable
Which is better on the above two points are debatable: YAML doesn't need closing tags (which are often better for clarity, like comments next to /TMPL_IF tags), but I think it has meaningful whitespace which I don't like because humans are poor at seeing whitespace.
- it supports pointed structures
Do we need them?
- it's now supported everywhere
Not everywhere, but probably comparable with XML. Does MySQL handle it now? I'm inclined towards XML because I know its tools better and my experience is that XML tools are more widely available, although I guess Koha requires both YAML and XML tools to be available. Hope that helps, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
On Wed, Jun 02, 2010 at 06:16:16PM +0100, MJ Ray wrote:
Which is better on the above two points are debatable
I have experience reading and editing both and i have to admit i hope to never see xml again out of its real place ( spanned text description ).
xml need closing tags (which are often better for clarity, like comments next to /TMPL_IF tags)
I didn't meant end tags but extratags. In yaml, you can write authors: - John Doe - Octave R. Gebel - Agathe dablooz then you have an array. The equivalent XML would be something like <authors> <element>John Doe</element> <element>Octave R. Gebel</element> <element>Agathe dablooz</element> </authors> element tag is there only because of xml serialization so you need extra config in to make your xmlparser add dans remove tags correctly when reading/writing files. Too error-prone for me.
which I don't like because humans are poor at seeing whitespace.
a point for xml ... but - as in xml: that parser will help you - errors are easier to fix by hand. By experience, it's easier to find a hash key without tailing space than tring to understand how an accidentaly removed char in a tag breaks all the tree.
- it supports pointed structures Do we need them?
It depends if we can extract informations and links without having references to the database ids - it will be hard to do it in some cases. For exemples: authorities are storing DB ids inside the marc record. - it will be the good strategy if we want a tool that is not just another mysql dumper (updating versions, merging 2 bases, ...)
- it's now supported everywhere
Not everywhere, but probably comparable with XML. Does MySQL handle it now?
mysql comes with its own grammar (sql) so why must sql have to know something about xml or yaml ? regards -- Marc Chantreux BibLibre, expert en logiciels libres pour l'info-doc http://biblibre.com
There are a few possibilities I see here. One is to create an export tool. Some MARC format would be good for the biblio and copy information, but there would have to be some framework, similar to that which is in the works for imports, to map koha fields to MARC fields. The system prefered MARC format would probably be used. Then a seperate button to generate a csv of the borrower information. This could be amended easily to be imported into different version of Koha by adding or removing columns in a spreadsheet application. Finially, another botton to generate a csv/xml/yaml file with issues, reserves, fines, serials. Maybe even split those to seperate buttons/files too. That's just one idea. And one of those features is already in place in the biblio exports. It would just need to be expanded to handle copy information. On Wed, 2010-06-02 at 13:49 +1200, Reed Wade wrote:
Maybe this is already solved but--
It seems like it would be fun if there was a nicely generic format defined for Koha data dumps. Is it correct that right now this is a DB specific task?
I'm thinking some format that would be good for--
- working across different versions of Koha (within reason) - portable backups - a stable interchange format when migrating between Koha and other ILSs - the case where some library is running v2 and it's really, really finally time for them to move to v12 and they now have the resources to do it
-reed _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
-- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha
participants (5)
-
Marc Chantreux -
Michael Hafen -
MJ Ray -
Reed Wade -
Rick Welykochy