This is the 'mutiple join conditions' feature that is wanted by just
about everybody but isn't in the system yet, to my understanding.
This pattern may work better given the current state of the code - AND
forces database constraint checking so you don't accidentally end up
putting in a object
Hello DBIx::Classy people,
I work on an application that is now using DBIx::Class (previously it
used Class::DBI) and I'd like to present the architecture for comment.
I'm relatively new to DBIx::Class and feel like I got in at the deep-end,
so may be doing things in an awkward manner. However,
[Please excuse resend, but first try was munged in daily digest, possibly due
to RTF characters]
Hi DBIx::Class hackers
Let's say we have two unrelated tables, "tag" and "asset", each with their own
sequence of auto-incrementing IDs (so of course the same ID may occur in both,
for records unr
Hi DBIx::Class hackers
Let's say we have two unrelated tables, "tag" and "asset", each with their own
sequence of auto-incrementing IDs (so of course the same ID may occur in
both, for records unrelated to each other).
Now suppose there is a third table, "edits", set up with a record to allow u
All,
I am pleased to announce that Set::Relation (relational types and operators for
Perl) versions 0.8.0 and 0.9.0 for Perl 5 have been released on CPAN.
http://search.cpan.org/dist/Set-Relation/
First, to briefly repeat the change information for last month's release 0.7.0
(from 0.6.0 which
