Handling relations

[theofidry]

If I have the following fixtures file:

MyApp\Entity\Dummy:
    dummy_{0...10}: {}

MyApp\Entity\RelatedDummy:
    related_dummy_{0...10}:
        dummy: @dummy*

It will work fine, however, if we inverse the order:

MyApp\Entity\RelatedDummy:
    related_dummy_{0...10}:
        dummy: @dummy*

MyApp\Entity\Dummy:
    dummy_{0...10}: {}

We get an error as the @dummy* mask didn't find any matching reference. There is also some other cases to consider:

• bidirectional relations
• when you set the relation via the constructor (seems to behave differently as when you set the relation via a setter/adder)
• when relations are in different files

This situation should not happen: the loader should be smart enough to handle such cases and the user shouldn't have to be concerned about that.

Same goes for parameters btw.

[theofidry]

@tshelburne it's really a major bug, when will you be able to take a look into it? It would be a pity to have to go back to the 1.x just for that...

[theofidry]

Little update, kind of solved this for now in HautelookAliceBundle via a custom loader.

[tshelburne]

It is a major bug, but it's also one that's pretty trivial to work around, given that it just takes ordering things "properly". That said, it's a bug I've felt the pain of in one of my larger projects, so I'm all for a solution similar to the one you used in the bundle. I'm not crazy about that particular implementation - my preference would be to break relationship hydration into a later step in the process - but it's certainly serviceable. Feel free to open a PR.

[theofidry]

The implementation is ugly: I'm basically doing multiple pass for the loading. It's a very straightforward solution I came up with but if someone has something more neat I'm all ears ;)

But the solution I've got works only when you break apport entities into different files. But the bug still occurs for entities in the same file. I tried to look a bit into it but I'm kind of lost to be honest. So my solution is more a workaround for my use case rather than a patch for Alice :/

[tshelburne]

I meant no offense, it certainly does the job for your use-case 👍

Re: the files restriction, good point. I've started a branch to do the "right" fix a few times (basically, load all entities, run processing on all non-relationship properties, and then do a final pass to hydrate relationships), but haven't had the adequate time to build it in. I've built JS implementations of object stores that function as "in-memory" databases using this pattern, and it's worked out decently well.

[theofidry]

I meant no offense, it certainly does the job for your use-case 👍

I'm not, but I can't say I'm proud of this implementation, looks ugly to me.

Re: the files restriction, good point. I've started a branch to do the "right" fix a few times (basically, load all entities, run processing on all non-relationship properties, and then do a final pass to hydrate relationships), but haven't had the adequate time to build it in. I've built JS implementations of object stores that function as "in-memory" databases using this pattern, and it's worked out decently well.

👯 🎉 👏

[theofidry]

Another issue about that too: the references handling should not be limited to 1 range deep. I mean right now we're talking about:

MyApp\Entity\Dummy:
    dummy_{0...10}: {}

MyApp\Entity\RelatedDummy:
    related_dummy_{0...10}:
        dummy: @dummy*

But the following should work too:

MyApp\Entity\Dummy:
    dummy_{0...10}: {}

MyApp\Entity\RelatedDummy:
    related_dummy_{0...10}:
        dummy: @dummy*

MyApp\Entity\RelatedOfRelatedDummy:
    related_of_related_dummy_{0...10}:
        dummy: @related_dummy*

and so on...

[theofidry]

Solved in 3.x and left as an implementation limitation in 2.x.

As said the problem can be mitigated in 2.x by having a custom Loader, but as alice loader is meant to be used as something to get started with and not something we want to make extendable and integration more features to, it's out of alice scope.