[Dbix-class] ANNOUNCE - Set::Relation versions 0.8.0 and 0.9.0 for Perl 5

Darren Duncan darren at darrenduncan.net
Wed Mar 25 09:36:28 GMT 2009


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 was the first initial-feature-complete release):
Set::Relation is now a role (or actually 2 roles, one immutable, one mutable),
so it is easier for user code to just say they accept any objects doing that
role, and the initial implementation was separated into another file called V1.
  It is now also easier for third parties to make distinct implementations if
they wish.  And yes, this role is in terms of an actual Moose role.

Now the main change in version 0.8.0 from version 0.7.0 is the addition of a
second bundled implementation of the Set::Relation role, called V2.
Feature-wise, V2 should have considerably better performance than V1 in general,
and especially for some use cases.  V2 also does strictly immutable objects
while V1 does mutable objects.  Design-wise, both V1 and V2 are similar in many
respects, including the use of a Perl Hash internally to represent each relation
tuple.  How they differ mainly is that V1 does eager tuple hashing and duplicate
elimination while V2 does lazy tuple hashing and duplicate elimination.  Another
feature change in 0.8.0 from 0.7.0 is that users have the option on some
Set::Relation method calls to say they accept less accuracy in results, so for
example they give permission for duplicate elimination to be skipped entirely,
and what they gain from this conceptually is an even greater speed increase.
Now the kind of operations where you would likely see the greatest speed
increase with V2 automatically, are for [new(), union(), insertion()] as they
are done with zero hashing or elimination; and to a lesser extent join() etc
since it only indexes the common attributes on the join; and optionally on
cardinality() and members extraction, as they also avoid all hashing/etc when
explicitly asked to, thereby the class sort-of doing multisets rather than sets
as normal.  In contrast with V2, operations like [intersection(), difference(),
deletion()] still incur indexing / duplicate elimination in order to make sure
all copies of a filtered-out tuple are eliminated.  Version 0.8.0 does not
introduce any major API changes or capability features.  Note that I recommend
V2 over V1 for actual use, where either would be useful; I don't consider them
on equal footing.

And the main change in version 0.9.0 from version 0.8.0 is the addition of
support for specifying candidate keys or (unique) key constraints on
Set::Relation objects at object creation time, and introspecting for candidate
keys on the objects after creation.  Version 0.9.0 was just a first draft of the
'keys' feature and it isn't very well integrated.  What is stated above is about
as far as it goes.  Still TODO is to actually exploit knowledge of keys to speed
up the relational operators, since you can do indexing or duplicate elimination
much less expensively if you know you only have to examine a subset of the
attributes' values.

On a related matter, today I updated
http://www.perlfoundation.org/perl5/index.cgi?gsoc_2009_projects to add a
student project idea to implement Perl 6 savvy relational types and operators,
starting with porting Set::Relation to Perl 6.  Now said port was something I
otherwise would have done within the next few months, and the Perl 5 module was
designed from day one that this would happen in mind, but I figured this was
something it would be nice to have a fresh outlook on, since someone else say a
student may come up with the functionality in much more idiomatic Perl 6 than I
would have.  And its not like any prerequisites they might need from me aren't
already done now; the existing Perl 5 version already illustrates the desired
features and behavior, which they are of course free to improve on.  Now in the
likely event that no student picks this up, I welcome input from you / the
community on how to do better than a straight port and provide better Perl 6
savvyness.

Thank you and have a good day. -- Darren Duncan





More information about the DBIx-Class mailing list