Drupal core does this same trick in locale module by adding empty translations on import and discovery of strings so it is able to INNER JOIN, which gets to use the right indexes. Localization community does add an empty placeholder translation when a suggestion is added, but a translation does not exist (so that has_suggestion can be tracked), and this should be converted to a practice where an empty translation exists at all times. Gerhard acknowledges this is more data, but as our tests showed, since the indexes get to be used, the performance of the resulting query is way better. We can eliminate IS NULL checking and convert the LEFT JOIN to INNER JOIN.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | l10n_join.patch | 15.95 KB | meba |
Comments
Comment #1
meba commentedI just realized this kind of doesn't make sense. Why? Because they only place we are refering to a LANGUAGE of the translation is the translation table itself. Therefore I can't just create an empty translation after creating a string - I don't have any language. I would have to create empty translation for every language enabled and that's a LOT of data. Also what happens when somebody creates a language? Should the empty translations be created as well?
Comment #2
gábor hojtsyYes and yes. This is what Drupal core does again. To be able to have inner join, all languages needs all their translations.
Comment #3
meba commentedAttaching patch which is incomplete and messes a lot of stuff together. I am just making sure i don't lose the code. It should make more sense once #375817: Performance: denormalize releases, files and lines with project/release info is committed.
Comment #4
gábor hojtsyComment #5
SebCorbin commentedBumping to 7.x as 6.x is now discontinued. With the new schema architecture, is is still relevant?
Comment #6
gábor hojtsyIt may help with performance, I don't know, we need to look into it.