Store origin data alongside localized data

[ryanmitchell]

As discussed here, we should store origin entry data alongside localisation data so it can be queried at the database level.

Let me know if youre happy with this approach as I'll need to add some test coverage on this before it should be merged.

[ryanmitchell]

Hmm actually this will only work on 1st save, after that localizable_fields will contain everything, which isnt right. What's the best way to get the fields that are actually localised - through the blueprint?

[FrittenKeeZ]

@ryanmitchell there also seems to be an issue with date not being updated for localized entries when the origin is changed and the date field isn't localizable

[what-the-diff[bot]]

• The Entry class now has a new method called makeLocalization().
• In the same file, we have added some code to the existing methods:
  • fromModel(): We are adding an extra line of code that will add localized fields as data in our entry object. This is done by using collect and only(). If there are no localized fields then it just returns all data for this model (line 14).

[ryanmitchell]

@FrittenKeeZ yep, I was battling the tests a bit so moved this to draft. Should be working now with the latest commit.

[FrittenKeeZ]

@ryanmitchell @jasonvarga we're facing rather big performance issues with blueprint being stored in json instead of its own field, so I just wanted to hear you out if you're okay with pulling blueprint out of json with an index so queries don't take 5+ seconds to complete?

[FrittenKeeZ]

@ryanmitchell do you have any sense of whether this is ready for use? The missing blueprint on translated entries are causing us big issues currently, so I'm torn between using this patch to get the missing data or creating a PR for storing blueprint in a separate field in the database for improving performance as well.

[ryanmitchell]

As far as I can see it is, but Jason may feel differently

[FrittenKeeZ]

We just talked it through with the team and I'll be making a PR to fix #126 soon, as it will fix three issues we have regarding performance, code complexity and data duplication for blueprint.

[FrittenKeeZ]

@ryanmitchell I can see I added some additional handling regarding parent, but I can't remember whether it was an issue or I just added it as a precaution. https://github.com/statamic/eloquent-driver/pull/144/files#diff-31fcf8a95fd0dbc8da9e8dc7ae856aa51bd921c50a8059e23df7d411737ab65fR71

[ryanmitchell]

Yeah we're not storing parent going forward - its redundant as we have origin as a column.

[FrittenKeeZ]

Yeah we're not storing parent going forward - its redundant as we have origin as a column.

It's not quite the same, especially when it comes to multisite. Origin is the fallback entry, but parent is the entry in the tree hierarchy which differs for each site.

[ryanmitchell]

Ah right, so german might be the parent of french, but english is the fallback? Ok, storing the ID is fine (as your PR did) - I think until this PR its storing the whole entry which is a lot.

[FrittenKeeZ]

Ah right, so german might be the parent of french, but english is the fallback? Ok, storing the ID is fine (as your PR did) - I think until this PR its storing the whole entry which is a lot.

Not quite... each site / language is its own regarding parents, like so:

                 Origin
Contact (EN)  - - - - - - - Kontakt (DE)
    |                         |
    | Parent                  | Parent
    |            Origin       |
About US (EN) - - - - - - - Über Uns (DE)

[ryanmitchell]

@FrittenKeeZ are you happy that this covers everything you found now?

[ryanmitchell]

Thanks @FrittenKeeZ