[DBIx-Class-Devel] [dbsrgits/dbix-class] Scalar::Defer support as column name (#98)

[Peter Rabbitson]

> As for SQL::Abstract doesn't seem like an issue, defer will return same result over and over

...? I just demonstrated in that oneliner that the thing is evaluated twice, not once.

> Main goal was to solve issues with joins. I use chained resultsets a lot, and they often go into ResultSet classes as helpers like "with_tag", "with_parent_tag"

Right. The correct answer to this is proper `alias` option support for join specifications, which has not yet been implemented due to various hurdles. I have not revisited this yet, and can not currently say for sure if I will be able to cover this before I depart.

> I guess they (join specs) should be sticky.

They can't be because the join spec is calculated lazily at the end of a callchain, ensuring proper deduplication can take place (e.g. `search({}, { join => 'foo')->search({}, { join => 'foo'})`. This does have the unintended effect of the entire thing "shifting" from under you when an identically named join is added on a **distinct yet parallel** relation branch. It is a limitation on the original design, and various deployments depend on various quirks of it, hence a large scale "sanity fix" is not on the cards (even if attributes are implemented, there still would likely be no system to avoid clashes).

There is however a separate technique allowing you to sidestep the problem entirely: use correlated subqueries. The concept is more or less the same but it is both less fragile (each subquery is an implicit namespace and clashes can not occur) and more efficient (most optimizers, including MySQL's, recognize that the join does not need to be reified).

You can either do this [by hand](https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082821/t/prefetch/correlated.t#L20-29), or use @frioux's [helper](https://metacpan.org/pod/DBIx::Class::Helper::ResultSet::CorrelateRelationship#SYNOPSIS) to achieve the same effect as described in the linked SYNOPSIS.

If this doesn't work for you - you will have to give up chaining for the time being, and build the structure separately from DBIC, only feeding it the final monolithic where+join criteria. The tooling is just not up to the task yet.

Even though I am closing this PR due to the considerations discussed higher up, feel free to add more thoughts/questions to this ticket if the above does not give you a satisfactory set of answers.

Cheers!

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dbsrgits/dbix-class/pull/98#issuecomment-204472911
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class-devel/attachments/20160401/6c2ff649/attachment.htm>