Operator Overloads in DBIC?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Operator Overloads in DBIC?

Paul Bennett
Hi, DBICers,

I have most of a spec (and a tiny bit of pseudocode) prepared for
adding operator overloads to Result Sets, to make it easier to write &
reuse pieces of queries in a style more like Relational Algebra &
Tuple-Relational Calculus. For instance, '/' for relational division,
'*' for fiber product, 'x' for explicit cross join, '|' for left
semijoin, '||' for left outer join, '.' for full outer join, '>' for
left antijoin, '+' for union, '&' for intersection, '-' for "except",
and so on.

The path of least resistance seems to be to subclass ResultSet and
some other classes.

However, if I subclass, then I (or someone) would end up writing
Dancer2::Plugin::DBIC::Algebra (or whatever the naming ends up being),
and so on for everything else that turns DBIC into a plugin (and I
understand this set to be non-trivial).

So. What's the best way to proceed? Just get coding and submit a
patchset? Is there a more-established way to get on-board? Some kind
of pre-approval process?


Thanks,


--
Paul W Bennett
P/PW/PWBENNETT

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator Overloads in DBIC?

Peter Rabbitson-2
On 03/07/2016 01:25 PM, Paul Bennett wrote:

> Hi, DBICers,
>
> I have most of a spec (and a tiny bit of pseudocode) prepared for
> adding operator overloads to Result Sets, to make it easier to write &
> reuse pieces of queries in a style more like Relational Algebra &
> Tuple-Relational Calculus. For instance, '/' for relational division,
> '*' for fiber product, 'x' for explicit cross join, '|' for left
> semijoin, '||' for left outer join, '.' for full outer join, '>' for
> left antijoin, '+' for union, '&' for intersection, '-' for "except",
> and so on.

This is an interesting experiment. It is especially intriguing how the
above will deal with corner cases of non-trivial-selection resultsets.

Please continue pursuing this ;)

>
> The path of least resistance seems to be to subclass ResultSet and
> some other classes.

Generally given your objective you'd need to subclass ResultSet *only*.
If you end up needing more - it is likely your overall design is
lacking, and you are strongly encouraged to seek further assistance from
the list and/or IRC.

>
> However, if I subclass, then I (or someone) would end up writing
> Dancer2::Plugin::DBIC::Algebra (or whatever the naming ends up being),
> and so on for everything else that turns DBIC into a plugin (and I
> understand this set to be non-trivial).

I am not sure what you mean by this. Any "dbic backend integration"
worth its salt simply takes a Schema class which provides the entire
related graph of Results and Resultsets. This is the case for
Dance2::Plugin::DBIC as well - all a user provides is 'schema_class'.

Your relational algebra plugin has no bearing on such an orthogonal
concept as "web framework model" - your users would simply
'load_components()' your plugin as part of their base resultset class.

>
> So. What's the best way to proceed? Just get coding and submit a
> patchset? Is there a more-established way to get on-board? Some kind
> of pre-approval process?

If you are asking "how would I go about including this experiment into
the core DBIx::Class::Resultset class" - the answer is simply: this can
not happen. Due to the sheer amount of code in the wild that slings
around resultset objects, the base class overloads are effectively
forever frozen like the rest of the API.

However as I described in the rest of my reply - the immutability of
DBIx/Class/ResultSet.pm is of little consequence. Your idea belongs
squarely in an extension/component, which due to DBIC's design is rather
natural and least-effort way to gain extra functionality.

For extra inspiration look through this library of ResultSet components:
https://metacpan.org/source/FREW/DBIx-Class-Helpers-2.032000/lib/DBIx/Class/Helper/ResultSet

Feel free to ask further questions - the underlying work is very
interesting!

Cheers

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator Overloads in DBIC?

Paul Bennett


On Mar 7, 2016 07:57, "Peter Rabbitson" <[hidden email]> wrote:
>
> On 03/07/2016 01:25 PM, Paul Bennett wrote:
>>
>> Hi, DBICers,
>>
>> I have most of a spec (and a tiny bit of pseudocode) prepared for
>> adding operator overloads to Result Sets, to make it easier to write &
>> reuse pieces of queries in a style more like Relational Algebra &
>> Tuple-Relational Calculus.
>
> This is an interesting experiment.

Thanks. You wouldn't believe the mess I got into trying to spec it before DBIC came into my life.

> It is especially intriguing how the above will deal with corner cases of non-trivial-selection resultsets.
>

I can't say that I don't expect interesting times.

> Please continue pursuing this ;)

Your enthusiasm has doubled my resolve.

>> However, if I subclass, then I (or someone) would end up writing
>> Dancer2::Plugin::DBIC::Algebra (or whatever the naming ends up being),
>> and so on

> Your relational algebra plugin has no bearing on such an orthogonal concept as "web framework model" - your users would simply 'load_components()' your plugin as part of their base resultset class.
>
> However as I described in the rest of my reply - the immutability of DBIx/Class/ResultSet.pm is of little consequence. Your idea belongs squarely in an extension/component, which due to DBIC's design is rather natural and least-effort way to gain extra functionality.
>
> For extra inspiration look through this library of ResultSet components:
> https://metacpan.org/source/FREW/DBIx-Class-Helpers-2.032000/lib/DBIx/Class/Helper/ResultSet

See, there are two words already that I wish I'd known before: helper & component. Some very interesting stuff there.

> Feel free to ask further questions - the underlying work is very interesting!
>

Thanks again. I hope I haven't bitten off more than I can chew, but time will tell.

--
Paul W Bennett
P/PW/PWBENNETT


_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator Overloads in DBIC?

Darren Duncan
In reply to this post by Paul Bennett
On 2016-03-07 4:25 AM, Paul Bennett wrote:
> I have most of a spec (and a tiny bit of pseudocode) prepared for
> adding operator overloads to Result Sets, to make it easier to write &
> reuse pieces of queries in a style more like Relational Algebra &
> Tuple-Relational Calculus. For instance, '/' for relational division,
> '*' for fiber product, 'x' for explicit cross join, '|' for left
> semijoin, '||' for left outer join, '.' for full outer join, '>' for
> left antijoin, '+' for union, '&' for intersection, '-' for "except",
> and so on.

Paul,

Firstly:  What are the exact semantics you would use for your relational
division, since there is more than one operation historically that has been
given that name?  I mean, express it in terms of other relational
algebra/calculus.  On a related note, it has been argued that this operation
isn't very useful in practice; do you see a use for it or are you just being a
completionist?

Secondly:  Have you considered using other symbols for these operators?  The
ones you chose don't in my mind bear much resemblance to their meaning, or I
otherwise prefer not to use math operators for set operations.

I recommend you use short alphanum names instead, or Unicode symbols, like this:

     ⊎ addition
     ∖ except
     ∩ intersect
     ∪ union
     ∆ symmetric difference
     ⨝ natural join (or ⋈ alternately)
     ⋊ semijoin
     ⋉ semijoin
     ⊿ antijoin
     ⨯ cross product
     ⟕ half outer join
     ⟖ half outer join
     ⟗ full outer join

Basically, the word versions are what people would normally use, they are easier
to type but in particular are more explicit on meaning, where your overloaded
symbolics mostly are not; the Unicode are for people who want a concise mathy
look and have a Perl version supporting Unicode operators.

Note that the addition and union only differ for multisets; for sets they are
the same operation.

-- Darren Duncan


_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Loading...