On Fri, 01 Mar 2013 17:19:00 +0100, Peter Rabbitson via RT
<bug-DBIx-Class@rt.cpan.org> wrote:
Show quoted text>> Resulting out of an IRC discussion i created the branch
>> "belongs_to_rename". It contains multiple commits that rename
>> belongs_to to refers_to,
>
> I need to start with a disclaimer - I do not want to demotivate you,
> this is something that we need to do for a very long time (the
> renaming). Yet your proposal suffers a semantical problem. Please read
> the rest as an attempt at objective criticism, not as an attempt to kill
> your effort outright.
No worries. I made those changes mostly to see what they'd end up being,
fully aware that they'll likely be partly or fully scrapped.
Show quoted text> This has come up many times in the past, and this patch *also* falls
> short of addressing the main problem. You are looking at belongs_to as
> an isolated method.
I'm doing so because that was how far i got in trying to use DBIC. To
explain, i have a table representing PPI elements, which i deploy() to an
empty sqlite database, which looks like this:
id | type | source | line | column | long_pattern | short_pat
.. | struc | ...[A] | ... | ... | ...[A] | ...[A]
.. | block | ...[A] | ... | ... | ...[A] | ...[A]
.. | struc | ...[B] | ... | ... | ...[B] | ...[B]
.. | struc | ...[C] | ... | ... | ...[C] | ...[B]
.. | block | ...[D] | ... | ... | ...[D] | ...[C]
.. | block | ...[E] | ... | ... | ...[D] | ...[C]
I'd like to remove duplication, by normalizing into something like this:
id | type | source | loc | long_pattern | short_pat
.. | struc | 1 | 1 | 1 | 1
.. | block | 1 | 1 | 1 | 1
.. | struc | 2 | 2 | 2 | 2
.. | struc | 3 | 3 | 3 | 2
.. | block | 4 | 4 | 4 | 3
.. | block | 5 | 5 | 4 | 3
Leaving out all but the source column, for now, my naive thought was: Each
element has one source string. Different elements might share the same,
but each has one. Turned out has_one was wrong for that though, it
should've been belongs_to (as far as functionality goes)
However, the source column is just metadata that i'd normally even throw
away and only keep around so i can print nicer reports about the harvested
data down the line. They're only separate because of memory concerns. In
fact, the elements belong so little to the source bits that the elements
*need* to be kept around even if the source bit is removed from the
database. The same would be true for location. In some analysis cases i
would not care at all where the element was located.
What happens here is that each element simply has a reference to a bit of
metadata.
In these two cases belongs_to does not accurately reflect the type of
relationship.
That is why, for now, i was only looking at belongs_to.
In the meantime i've had more time to think about it, which is partly why
my table up there contains two more columns. Each of the elements will be
compressible, via different algorithms, into code patterns. These are not
simply metadata for my purposes, they actually stand for groups of things.
And each element belongs to one group and each element is only useful if
it belongs to these groups.
As such, for those relationships belongs_to is perfectly correct.
So, as far as i can tell (and i might be entirely wrong due to my
inexperience) there are two semantically different cases that are
implemented by belongs_to() in the same manner.
So right now i'm thinking that both need to be around.
Show quoted text> other relationships
I'm sorry, i still have not gotten that far (aside from being told to
never use has_one) and cannot useful opine on those. I will need to
actually read the documentation before doing so, but did not wish to leave
you waiting for a reply until i've done so.
Show quoted text> owned_by / maybe_owned_by / owns_one / maybe_owns_one / owns_many
Looking at those i'd choose maybe_owns_one for location and source, and
owned_by for the pattern groups, expecting DBIC to generate the table
layout above. Is that what you're thinking?
Show quoted text>> As for the alias of belongs_to to refers_to, my original notion was
>> simply to do `*belongs_to = \&refers_to;`, however that caused
>> `55namespaces_cleaned.t` to complain about mismatching names of
>> function and GV. Thus i solved it with `goto \&refers_to`. If that is
>> not desired, suggestions welcome.
>
> You may never do this in OO programming. Because if someone is
> overriding the refers_to method, and then another user calls the
> belongs_to proxy, perl will dispatch to the original refers_to, not the
> override. You always do:
>
> sub old_name { shift->new_name(@_) }
Noted. I thought about this, but did not like it due to the performance
impact. If we can agree on names, i will do that.
Show quoted text> Furthermore the exceptions need to be doubled up, to throw text
> containing 'belongs_to' when the exception is a result of calling a
> 'belongs_to'. A 'refers_to' containing error message in an old codebase,
> where refers_to does not exist will be very confusing.
Ah, i was looking at that, but wasn't sure if it was necessary or not.
--
With regards,
Christian Walde
