not_null shortcut

[moltar]

What do you think about having a not_null shortcut?

Example from my own use:

=head2 not_null($column)

Ensure that given C<$column> is not null.

=cut

sub not_null {
    my ($self, $column) = @_;

    return $self->search_rs({ $self->me($column) => { '!=' => undef } });
}

[frioux]

Seems legit to me; should we make a null, like, and not_like too while we're at it?

@wesQ3 thoughts?

[wesQ3]

Sounds good. We're probably overdue for some search condition shortcuts rather than just smoothing out search attributes.

[frioux]

@moltar if you send a PR with docs and tests (you're halfway there!) I'll look at merging it. Otherwise this'll go on the stack and I'll release it before too long.

[moltar]

Should each go into a separate package or do we bundle them into some namespace, like SearchShortcuts?

[frioux]

Good question. I think that each one should be a separate package, but they should all be used in SearchShortcuts. That way if the user wants everything they just use SearchShortcuts but if they want to not use a few they can do that.

[moltar]

Another question. Should be prefix them with "me." via ->me method or should we leave this exercise up to the user?

[frioux]

Do what I did in datemethods! If the user does .foo, prefix; if the user does just foo, leave it alone.

[moltar]

So I was trying to figure out what the best name space would be. My proposition is:

DBIx::Class::Helper::ResultSet::Shortcut::Search::$NAME

And then just load them up in DBIx::Class::Helper::ResultSet::Shortcut with all the other ones?

Or do we want them to load separately?

[frioux]

Yeah that namespace sounds perfect, just load it into Shortcut

sent from a rotary phone, pardon my brevity
On Mar 27, 2015 10:20 AM, "moltar" notifications@github.com wrote:

So I was trying to figure out what the best name space would be. My
proposition is:

DBIx::Class::Helper::ResultSet::Shortcut::Search::$NAME

And then just load them up in DBIx::Class::Helper::ResultSet::Shortcut
with all the other ones?

Or do we want them to load separately?

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[moltar]

Added in #47

[frioux]

This looks good @moltar. Could you remove the headers from the methods that already have POD documentation? The ones for private methods are fine. Thanks!

[moltar]

Done.

[frioux]

released!