For a new project we have a lot of propel i18n objects. The
implementation of the project is to show the preferred language of an
object and if that is not available show a secondary or third language
(fallback). Each object is always available in at least one language,
but not in all languages.
We implemented this using the default i18n behavior. After that we
added a magic __call method that calls a getXXXwithFallback() method
to make sure the getter always returns a result (in case the retrieved
object doesn't have the demanded language). Of course this fires
another database call, querying the i18n table for the secondary (or
third) translation of that object.
Now that the application grows bigger we need to reduce the query
count, and thats where the problem occurs.
A snippet of code that would create a lot of queries would be :
$structure = $structurPeer::doSelectWithI18n(new criteria());
foreach ($structure as $unit) {
echo $unit->getTitlewithFallBack();
}
For all objects that have the requested language, there is no
problem.
For the objects that do not have this requested language, a query is
fired
I would like to get some thoughts & comments how to solve/improve this
implementation.
Our own conclusions/possible workarounds :
- not use i18n but create a column for each language (title_nl,
title_fr), then convert the getTitleWithFallback method to check the
different columns and return the correct one. We can do this since we
have a limited nr of languages.
- when creating the object, make sure that for each language a i18n
record is created, cloning the original content of the objects primary
language
- somehow hack (perhaps propel1.5) propel core to provide
doSelectWithI18NWithFallback method, making sure the one-to-many
relationship (i18n) populates the array of related languages with only
one database query, and thus avoiding
Pro's & Cons :
- option#1 :
- pro : pretty easy to implement
- con : takes an amount of work adding future languages
- con : forms (embedi18n) need to be redone/adapted
- con : table layout will become messy
- option#2 :
- pro : easy to implement (using a task for all current objects)
- pro : stay within the symfony i18n system
- con : harder to determine the availability of different object
languages (as content is cloned)
- con :
- option#3 :
- pro : hydration of related objects with only one query
- con : dive into propel core
- con : pull hair out diving into propel core
- con : risk going crazy playing with propel relations (one-to-many)
I think option #2 is the better & easiest one. But i want to make sure
we are making the right decision here. Any thoughts ?
--
You received this message because you are subscribed to the Google Groups
"symfony users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en.
