From werner.bruhin at free.fr Thu Jun 9 11:56:15 2005 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Thu Jun 9 11:55:41 2005 Subject: [orm-devel] one2many problem in 1.0.1 when using getattr Message-ID: <42A8123F.9060500@free.fr> Hi Diedrich, Can you point me in the right direction on how to fix this problem in 1.0.1. In 0.16 Changing the example test_one2many.py to include this: print '---- getattr ----' print getattr(p, 'children') print '---- getattr end ----' Results in: ---- getattr ---- [, , , , ] ---- getattr end ---- In 1.0.1: Changing the example one2many_relationship.py to include this: print '---- getattr ----' print getattr(diedrich, 'emails') print '---- getattr end ----' Results in: ---- getattr ---- SELECT email.local, email.remote, email.id FROM email WHERE person_id=1 ---- getattr end ---- Best regards Werner Configuration: Python 2.4.1 Orm 1.0.1 or 0.16 Firebird 1.5 From werner.bruhin at free.fr Fri Jun 10 14:00:05 2005 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Fri Jun 10 13:59:23 2005 Subject: [orm-devel] one2many problem in 1.0.1 when using getattr In-Reply-To: <42A8123F.9060500@free.fr> References: <42A8123F.9060500@free.fr> Message-ID: <42A980C5.80700@free.fr> Hi Diedrich, Just looked at this again and I see that I can either iterate over it or even better just do a fetchall to get to my list the way I got it in 0.16. So, I assume this is intended behavior in 1.0.1, can you just confirm. See you Werner Werner F. Bruhin wrote: > Hi Diedrich, > > Can you point me in the right direction on how to fix this problem in > 1.0.1. > > In 0.16 > Changing the example test_one2many.py to include this: > print '---- getattr ----' > print getattr(p, 'children') > print '---- getattr end ----' > > Results in: > ---- getattr ---- > [, (pyid=11153360 oid=1 child_data='child data 2' id=2>, (pyid=11182208 oid=1 child_data='child data 3' id=3>, (pyid=11182328 oid=1 child_data='child data 4' id=4>, (pyid=11182448 oid=1 child_data='child data 5' id=5>] > ---- getattr end ---- > > In 1.0.1: > Changing the example one2many_relationship.py to include this: > print '---- getattr ----' > print getattr(diedrich, 'emails') > print '---- getattr end ----' > > Results in: > ---- getattr ---- > SELECT email.local, email.remote, email.id FROM email WHERE person_id=1 > > ---- getattr end ---- > > Best regards > Werner > > Configuration: > Python 2.4.1 > Orm 1.0.1 or 0.16 > Firebird 1.5 > > _______________________________________________ > orm-devel mailing list > orm-devel@mailman.tux4web.de > http://mailman.tux4web.de/mailman/listinfo/orm-devel > > > From diedrich at tux4web.de Mon Jun 13 14:59:50 2005 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Mon Jun 13 14:59:12 2005 Subject: [orm-devel] one2many problem in 1.0.1 when using getattr In-Reply-To: <42A980C5.80700@free.fr> References: <42A8123F.9060500@free.fr> <42A980C5.80700@free.fr> Message-ID: <7ACAE09C-146F-47DC-B968-3A3067C394E7@tux4web.de> Hi Werner, > Just looked at this again and I see that I can either iterate over > it or even better just do a fetchall to get to my list the way I > got it in 0.16. > > So, I assume this is intended behavior in 1.0.1, can you just confirm. confirmed! Getting the value of a relationship-attribute will always cause a SELECT query and return a selectResult, not a list. Values are not cached anymore. To get the children as a list I always write children = list(parent.attribute), but this is only needed if you iterate over the children more than once. Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From werner.bruhin at free.fr Tue Jun 14 16:07:37 2005 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Tue Jun 14 16:06:44 2005 Subject: [orm-devel] orm and epydoc Message-ID: <42AEE4A9.8020700@free.fr> Hi Diedrich, I liked the API doc so much on your web site that I downloaded epydoc and generated things on my machine. After reading some of the epydoc documentation I wonder what your plans are in respect to these API docs. Will you start using things like: @param columnName: the name of the SQL column we're resonsible for instead of: :columnName: the name of the SQL column we're resonsible for What about @return and @type? I am also getting quite a few warning errors such as "method's parameters do not match the parameters of the base class methods that they override, so documentation was not inherited" for e.g. orm.columns._integer.convert (base method = orm.columns._numerical.convert) I am fixing all the "impropert indentation" errors for Firebird, do you want me to fix the ones in other files too? See you Werner From diedrich at tux4web.de Thu Jun 16 09:33:09 2005 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Thu Jun 16 09:32:09 2005 Subject: [orm-devel] orm and epydoc In-Reply-To: <42AEE4A9.8020700@free.fr> References: <42AEE4A9.8020700@free.fr> Message-ID: <35E0553D-BA11-4EAB-AA01-F72F6C4A315D@tux4web.de> > After reading some of the epydoc documentation I wonder what your > plans are in respect to these API docs. > Will you start using things like: > @param columnName: the name of the SQL column we're > resonsible for Yes, I am going to go over the whole source and use epydoc style comments. > What about @return and @type? Those also... > I am fixing all the "impropert indentation" errors for Firebird, do > you want me to fix the ones in other files too? Well, thanks! I guess I'll do it here, though, because I have to overhaul the sources anyway and a lot of little things have been changed since the last version so I can't just copy your files back. Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From werner.bruhin at free.fr Fri Jun 17 12:10:03 2005 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Fri Jun 17 12:08:22 2005 Subject: [orm-devel] How to handle multi language? Message-ID: <42B2A17B.3080501@free.fr> Hi All, My application supports multiple languages (en, de, fr), my current implementation works but I think there is "space for improvement" and I am looking for some hints/suggestions on how to do this. Currently the "multi lang" table have a structure similar to this: ID, LANGID, NAME Which would have entries like this for a country table: 1, 1, Germany 1, 2, Deutschland 1, 3, Allemagne etc etc When user selects his/her language I create a "single lang" table from the "multi lang" one, e.g. if selected "en" I would get a table with just the English language entries (in above sample with LANGID = 1). One additional thing I did is that if one selected e.g. "de" (in above sample with LANGID = 2) and a particular record did NOT have a German translation I would copy the english translation into the single lang table. This all works but it means maintaining additional tables and worse makes it impossible for one user selecting German and the other user on the same system using English. So, I am looking for ideas on how I could do this just having the multiple language tables and allowing each user to select his/her language. Thanks in advance for any ideas and/or hints. Werner From werner.bruhin at free.fr Fri Jun 17 12:12:27 2005 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Fri Jun 17 12:10:41 2005 Subject: [orm-devel] other mails Message-ID: <42B2A20B.6030400@free.fr> Hi Diedrich, I sent some mails (e.g. yesterday "changes to 1.0.1") to your e-mail "diedrich@tux4web.de" and I am not sure if you got them. See you Werner From diedrich at tux4web.de Fri Jun 17 12:52:48 2005 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Fri Jun 17 12:51:18 2005 Subject: [orm-devel] How to handle multi language? In-Reply-To: <42B2A17B.3080501@free.fr> References: <42B2A17B.3080501@free.fr> Message-ID: <74F8D80F-B92D-4283-A5CC-EA1CC2944F3D@tux4web.de> Hi Werner! > My application supports multiple languages (en, de, fr), my current > implementation works but I think there is "space for improvement" > and I am looking for some hints/suggestions on how to do this. > Thanks in advance for any ideas and/or hints. I've got an idea I used for a web application, It's not ideal, though. I used one column per table per language like this: CREATE TABLE something ( title_de TEXT, description_de TEXT, title_en TEXT, description_en TEXT ); I'm using Livinglogic's XIST XML handling library to create XHTML output which represents the XHTML DOM tree using Python classes. I inserted the relevant data into the dom tree with the HTML attribute lang="" set to the correct language. Just previous to delivery I have a little routine walk the DOM tree an delete all entries that do not fit the user's language. If you are writing a GUI application you might want to create the model-Module (the one with all the dbclasses in) on startup depending on the user's language settings. Than you could mangle the columns dicts according to the locale. Like this (just a code-sketch) from orm.dbclass import dbclass from orm.columns import * from orm.firebird.columns import * class something(dbclass): pass something_columns = ( ("title", text, "title_%s"), ("description", text, "description_%s"), ) class someting_else(dbclass): pass something_columns = ( ("blah", text, "blah_%s"), ("blub", text, "blub_%s"), ) # figure out my locale, determine language abriviation, store it in lang variable for class_name in ("something", "something_else"): dbclass = locals()[class_name] column_tuples = locals()[class_name] columns_dict = {} for attribute_name, column_class, sql_column_name in column_tuples: columns_dict[attribute_name] = column_class (column_name="sql_column_name" % lang) dbclass.columns = columns_dict # now you can normaly instantiate something and something_else There is another idea I had: a dict_relationship that would let you access different columns in a dbclass like a dict as in dbobj.attribute[lang] which maps to SQL column dbobj's attribute_"lang"-column. Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From diedrich at tux4web.de Fri Jun 17 12:54:08 2005 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Fri Jun 17 12:52:30 2005 Subject: [orm-devel] other mails In-Reply-To: <42B2A20B.6030400@free.fr> References: <42B2A20B.6030400@free.fr> Message-ID: > I sent some mails (e.g. yesterday "changes to 1.0.1") to your e- > mail "diedrich@tux4web.de" and I am not sure if you got them. Yes, I did, thank you very much! Sorry for not replying right away, my computer work has low priority right now, sorry about that! Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From werner.bruhin at free.fr Fri Jun 17 21:12:27 2005 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Fri Jun 17 22:16:50 2005 Subject: [orm-devel] How to handle multi language? In-Reply-To: <74F8D80F-B92D-4283-A5CC-EA1CC2944F3D@tux4web.de> References: <42B2A17B.3080501@free.fr> <74F8D80F-B92D-4283-A5CC-EA1CC2944F3D@tux4web.de> Message-ID: <42B3209B.7050604@free.fr> Hi Diedrich, All your suggestions got me thinking. Whenever you or anyone else has a moment to look at the attached, I would be greatful for comments/critics - this is nothing urgent. So, I thought why not use a kind of a relation? I put something together roughly based on the many2one relationship, it only allows for "get"ing language specific data. I am not sure if this approach would hold up some serious testing/usage. I basically created a "lang2one" relationship, it allows to define a default language and a preferred language, if later is found the data for it is returned, otherwise the data for the default language is returned. I don't think that the naming of attributes etc I choose is that good. I am not that happy with all these fields defined for the country table, initially I had a setLanguage method in the lang2one relation but couldn't make it work. Files attached: relationships.py - this lives in adapter/firebird (if a generic solution is agreed on/found it should live in orm/relationships.py) lang2one* - live in examples/firebird Any hints, comments, critic (but be nice, please!) is very welcome Werner Diedrich Vorberg wrote: > Hi Werner! > >> My application supports multiple languages (en, de, fr), my current >> implementation works but I think there is "space for improvement" >> and I am looking for some hints/suggestions on how to do this. > > >> Thanks in advance for any ideas and/or hints. > > I've got an idea I used for a web application, It's not ideal, > though. I used one column per table per language like this: > > CREATE TABLE something > ( > title_de TEXT, > description_de TEXT, > title_en TEXT, > description_en TEXT > ); > > I'm using Livinglogic's XIST XML handling library to create XHTML > output which represents the XHTML DOM tree using Python classes. I > inserted the relevant data into the dom tree with the HTML attribute > lang="" set to the correct language. Just previous to delivery I have > a little routine walk the DOM tree an delete all entries that do not > fit the user's language. > > If you are writing a GUI application you might want to create the > model-Module (the one with all the dbclasses in) on startup depending > on the user's language settings. Than you could mangle the columns > dicts according to the locale. Like this (just a code-sketch) > > from orm.dbclass import dbclass > from orm.columns import * > from orm.firebird.columns import * > > class something(dbclass): > pass > > something_columns = ( ("title", text, "title_%s"), > ("description", text, "description_%s"), ) > > class someting_else(dbclass): > pass > > something_columns = ( ("blah", text, "blah_%s"), > ("blub", text, "blub_%s"), ) > > # figure out my locale, determine language abriviation, store it > in lang variable > > for class_name in ("something", "something_else"): > dbclass = locals()[class_name] > column_tuples = locals()[class_name] > > columns_dict = {} > for attribute_name, column_class, sql_column_name in > column_tuples: > columns_dict[attribute_name] = column_class > (column_name="sql_column_name" % lang) > > dbclass.columns = columns_dict > > # now you can normaly instantiate something and something_else > > > There is another idea I had: a dict_relationship that would let you > access different columns in a dbclass like a dict as in > > dbobj.attribute[lang] > > which maps to SQL column dbobj's attribute_"lang"-column. > > > Diedrich > -------------- next part -------------- A non-text attachment was scrubbed... Name: relationships.py Type: application/x-python Size: 4787 bytes Desc: not available Url : http://mailman.tux4web.de/pipermail/orm-devel/attachments/20050617/09d60439/relationships-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: lang2one_relationship.py Type: application/x-python Size: 2617 bytes Desc: not available Url : http://mailman.tux4web.de/pipermail/orm-devel/attachments/20050617/09d60439/lang2one_relationship-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: lang2one_relationship.sql Type: application/octetstream Size: 3378 bytes Desc: not available Url : http://mailman.tux4web.de/pipermail/orm-devel/attachments/20050617/09d60439/lang2one_relationship-0003.bin From diedrich at tux4web.de Sat Jun 18 11:20:35 2005 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Sat Jun 18 11:18:53 2005 Subject: [orm-devel] How to handle multi language? In-Reply-To: <42B3209B.7050604@free.fr> References: <42B2A17B.3080501@free.fr> <74F8D80F-B92D-4283-A5CC-EA1CC2944F3D@tux4web.de> <42B3209B.7050604@free.fr> Message-ID: Hi Werner! > All your suggestions got me thinking. Whenever you or anyone else > has a moment to look at the attached, I would be greatful for > comments/critics - this is nothing urgent. > Any hints, comments, critic (but be nice, please!) is very welcome Thank you very much for sharing your ideas with the list! I'd like to make two remarks, though: 1. I don't think it is a good idea to have several rows per language in the same table. This is going to make SELECT queries less streight forward, because you always have to exclude those entries you don't want for the current language. (If the parent table is the only one you do SELECTs on that's not a problem, of course). Anyway, I'd like to have one row per country, though dispite the face that there are three country names, it's only one country. 2. Just a small one: I think lang_2oneColumn can be optimized by using a JOIN so you don't need to run two queries. Have a nice weekend! Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From werner.bruhin at free.fr Tue Jun 21 13:18:58 2005 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Tue Jun 21 15:15:26 2005 Subject: [orm-devel] How to handle multi language? In-Reply-To: References: <42B2A17B.3080501@free.fr> <74F8D80F-B92D-4283-A5CC-EA1CC2944F3D@tux4web.de> <42B3209B.7050604@free.fr> Message-ID: <42B7F7A2.2040609@free.fr> Hi Diedrich, Diedrich Vorberg wrote: > Hi Werner! > >> All your suggestions got me thinking. Whenever you or anyone else >> has a moment to look at the attached, I would be greatful for >> comments/critics - this is nothing urgent. >> Any hints, comments, critic (but be nice, please!) is very welcome > > Thank you very much for sharing your ideas with the list! > > I'd like to make two remarks, though: > > 1. I don't think it is a good idea to have several rows per language > in the same table. This is going to make SELECT queries less streight > forward, because you always have to exclude those entries you don't > want for the current language. (If the parent table is the only one > you do SELECTs on that's not a problem, of course). All the "multi language" tables are what I call master data (Stamm Daten) type tables, they don't change much and they are not that often used in SELECT queries except in cases to fill e.g. a combobox but in that case I have to select the appropriate language anyhow, so I either do a SELECT with a where clause or decide which column to use. > Anyway, I'd like to have one row per country, though dispite the face > that there are three country names, it's only one country. You are right there should only be one row per thing (country in this case), I am not really happy with my solution nor with your's, so it is probably back to the drawing board. I use gettext for the program labels, maybe one could base it on their approach. The text to translate becomes the "ID" to find the translation, i.e. have a column type "TRANSLATE" which does a lookup in a table containing translations if the language ID is found for the "ID" that entry is used otherwise the "ID" is used. > > 2. Just a small one: I think lang_2oneColumn can be optimized by > using a JOIN so you don't need to run two queries. > > Have a nice weekend! > Diedrich > Hope you had a nice weekend, here it was a bit too hot for my taste but very nice evenings. See you Werner From reedstrm at rice.edu Wed Jun 22 20:08:11 2005 From: reedstrm at rice.edu (Ross J. Reedstrom) Date: Wed Jun 22 20:05:58 2005 Subject: [orm-devel] How to handle multi language? In-Reply-To: <42B7F7A2.2040609@free.fr> References: <42B2A17B.3080501@free.fr> <74F8D80F-B92D-4283-A5CC-EA1CC2944F3D@tux4web.de> <42B3209B.7050604@free.fr> <42B7F7A2.2040609@free.fr> Message-ID: <20050622180811.GB1152@cnx.rice.edu> Hi Deidriech and Werner - I've been lurking here as well, so don't think you're talking in a vacuum. Haven't had a chance to use ORM much recently, but we _have_ been thinking aobut translation issues. On Tue, Jun 21, 2005 at 01:18:58PM +0200, Werner F. Bruhin wrote: > >Anyway, I'd like to have one row per country, though dispite the face > >that there are three country names, it's only one country. > > You are right there should only be one row per thing (country in this > case), I am not really happy with my solution nor with your's, so it is > probably back to the drawing board. > > I use gettext for the program labels, maybe one could base it on their > approach. > > The text to translate becomes the "ID" to find the translation, i.e. > have a column type "TRANSLATE" which does a lookup in a table containing > translations if the language ID is found for the "ID" that entry is used > otherwise the "ID" is used. I think this is a reasonably good idea, except for using the ID as the default translation: even with gettext, if the string is reasonably long, its common practice to assign an actual ID. I think for a real database, that's the right way to go from the beginning. So defaulting becomes using a COALESCE, with one column per language, in order of preference: SELECT COALESCE(gr_tran,fr_tran,en_tran) as txt FROM texts WHERE txtid = 123; would return the first non-NULL translation for an order of pref: German, French, and English. Ross -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Research Scientist phone: 713-348-6166 The Connexions Project http://cnx.rice.edu fax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE Ross From diedrich at tux4web.de Wed Jun 22 20:52:10 2005 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Wed Jun 22 20:49:52 2005 Subject: [orm-devel] How to handle multi language? In-Reply-To: <20050622180811.GB1152@cnx.rice.edu> References: <42B2A17B.3080501@free.fr> <74F8D80F-B92D-4283-A5CC-EA1CC2944F3D@tux4web.de> <42B3209B.7050604@free.fr> <42B7F7A2.2040609@free.fr> <20050622180811.GB1152@cnx.rice.edu> Message-ID: Hi Ross, > SELECT COALESCE(gr_tran,fr_tran,en_tran) as txt FROM texts WHERE txtid > = 123; to do this, an expression column comes in handy. It's probably a good idea to define a column class, which is a subclass of text (or rather Unicode) that takes a tuple of column names as an attribute and maps them to COALESCE() calls. Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From werner.bruhin at free.fr Thu Jun 23 12:41:02 2005 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Thu Jun 23 12:38:37 2005 Subject: [orm-devel] How to handle multi language? In-Reply-To: References: <42B2A17B.3080501@free.fr> <74F8D80F-B92D-4283-A5CC-EA1CC2944F3D@tux4web.de> <42B3209B.7050604@free.fr> <42B7F7A2.2040609@free.fr> <20050622180811.GB1152@cnx.rice.edu> Message-ID: <42BA91BE.2060305@free.fr> Hi Ross and Diedrich, Diedrich Vorberg wrote: > Hi Ross, > >> SELECT COALESCE(gr_tran,fr_tran,en_tran) as txt FROM texts WHERE >> txtid = 123; > > to do this, an expression column comes in handy. It's probably a good > idea to define a column class, which is a subclass of text (or rather > Unicode) that takes a tuple of column names as an attribute and maps > them to COALESCE() calls. > Why are you both leaning to the column per language approach instead of a row per language approach (txtid, langid, text). I have the following concerns/problems with the column per language approach: - Requires table restructure for new language - Potentially large row, currently I only support three languages, so no big deal, but I see systems with many more languages. I only see the following concern/problem with the row per language approach are: - Potentially multiple SELECTS if preferred language is not found Thanks to both of you for taking the time to think about this problem. See you Werner From diedrich at tux4web.de Thu Jun 23 22:21:06 2005 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Thu Jun 23 22:52:01 2005 Subject: [orm-devel] How to handle multi language? In-Reply-To: <42BA91BE.2060305@free.fr> References: <42B2A17B.3080501@free.fr> <74F8D80F-B92D-4283-A5CC-EA1CC2944F3D@tux4web.de> <42B3209B.7050604@free.fr> <42B7F7A2.2040609@free.fr> <20050622180811.GB1152@cnx.rice.edu> <42BA91BE.2060305@free.fr> Message-ID: Hi Werner, > Why are you both leaning to the column per language approach instead > of a row per language approach (txtid, langid, text). for me personally it's about design and clean modeling, really. One data-entity (i.e. row) per real world object. It just "makes sense" to me. There's an alternative, though: one table per language, containing all localizable columns, one table with the non-locale depending data, sharing a single primary key. As in CREATE TABLE tree ( tree_id SERIAL, height INTEGER NON NULL, color TEXT NON NULL DEFAULT 'green' ); CREATE TABLE tree_de ( tree_id INTEGER REFERENCES tree(id), name TEXT ); To retrieve data one would JOIN the tree table with the "tree_%s" % lang table. This could be accomplished using orm's join class. To modify data you'd need one dbclass for the common data, one for each language table, whoes columns dict is a deep copy of a template. This could be a compromise, perhaps? ;-) Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From werner.bruhin at free.fr Fri Jun 24 12:21:01 2005 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Fri Jun 24 12:19:47 2005 Subject: [orm-devel] How to handle multi language? In-Reply-To: References: <42B2A17B.3080501@free.fr> <74F8D80F-B92D-4283-A5CC-EA1CC2944F3D@tux4web.de> <42B3209B.7050604@free.fr> <42B7F7A2.2040609@free.fr> <20050622180811.GB1152@cnx.rice.edu> <42BA91BE.2060305@free.fr> Message-ID: <42BBDE8D.4080702@free.fr> Hi Diedrich, Diedrich Vorberg wrote: > Hi Werner, > >> Why are you both leaning to the column per language approach instead >> of a row per language approach (txtid, langid, text). > > for me personally it's about design and clean modeling, really. One > data-entity (i.e. row) per real world object. It just "makes sense" to > me. But what is the real world object in this case? I am not talking about the country here but the translation! For you being German (am I right) and me being Swiss (of the german variety ;-) ) the real world object is "Deutschland" but as I live in the South of France it could also be "Allemagne" or for my wife (New Zealander) it would be "Germany". > > There's an alternative, though: one table per language, containing all > localizable columns, one table with the non-locale depending data, > sharing a single primary key. As in > > CREATE TABLE tree > ( > tree_id SERIAL, > height INTEGER NON NULL, > color TEXT NON NULL DEFAULT 'green' > ); > > CREATE TABLE tree_de > ( > tree_id INTEGER REFERENCES tree(id), > name TEXT > ); > > To retrieve data one would JOIN the tree table with the "tree_%s" % > lang table. This could be accomplished using orm's join class. To > modify data you'd need one dbclass for the common data, one for each > language table, whoes columns dict is a deep copy of a template. > > This could be a compromise, perhaps? ;-) My initial reaction was this is even worse then having a column per language but :-\ (undecided), I will sleep over it. > > Diedrich > See you and thanks again for comming up with suggestions/ideas. Werner