Re: [Dbix-class] What's the best way to join with an aggregated query in DBIC

[Karen Etheridge]

It sounds like you are doing a correlated subquery -- take a look at
DBIx::Class::Helper::ResultSet::CorrelateRelationship (thank you so much
frew!)

On Wed, Jan 27, 2021 at 5:50 AM Veesh Goldman  wrote:

> have you tried ->as_subselect_rs? That should be what you're looking for.
> Just make sure to define your "columns" on the subselect, or else it will
> try to get all the cols from the original table.
>
> On Wed, Jan 27, 2021 at 1:22 PM Robert Rothenberg 
> wrote:
>
>> I have an aggregated query
>>
>>$rs->search_rs( undef, {
>>  columns => [
>>"me.id",
>>{ total => \ "SUM(me.val)" }
>>  ],
>>  group_by => [ "me.id" ],
>>} );
>>
>>
>> I would like to join the results with another table, but that requires
>> adding the columns to the group by clause.
>>
>> It's faster to do something like
>>
>> SELECT a.*, y.* from (select id, sum(val) from x group by id) a join
>> y on a.id=y.x_id
>>
>> Is there a way in DBIC to do that, without creating a virtual result
>> source?
>>
>>
>> ___
>> 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@lists.scsys.co.uk
>
> ___
> 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@lists.scsys.co.uk
___
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@lists.scsys.co.uk

Re: [Dbix-class] Restore old behavior of DBIx::Class::Loader

[Karen Etheridge]

"Aux" is not a special prefix in DBICL -- did some of your table names
change?
You can override how some of the names work with a configuration file --
see all the options documented in DBIx::Class::Schema::Loader;:Base. I
suspect you can do what you need with some entries in 'moniker_map'.
Perhaps you had a configuration file before but it was removed after the
last regeneration was done?

On Wed, Jul 8, 2020 at 5:23 AM Александр Поволоцкий  wrote:

> Hello
>
> I'm developing a project of about 36000 lines of perl code for now, and
> some time ago I've found that dbicdump begins to process monikers' names
> differently.
>
> Sample diff of one of generated modules
>
>   Type: belongs_to
>
> -Related object: L
> +Related object: L
>
>   =cut
>
>   __PACKAGE__->belongs_to(
> "state",
> -  "Billing::Schema::Result::ClientState",
> +  "Billing::Schema::Result::AuxClientState",
> { id => "state" },
> { is_deferrable => 0, on_delete => "NO ACTION", on_update => "NO
> ACTION" },
>   );
>
> To avoid checking all my code for changed names, I have only two
> options: manually merge changes into modules or restore original naming
> for dbicdump.
>
> However, I could not find the right combination of keys, tried v5, v6,
> v7, v8 naming, tried to set namespaces to 0 and 1, but nothing produces
> the desired result.
>
> Maybe someone knows the magic?
>
> ---
>
> Alex
>
>
> --
> Это сообщение проверено на вирусы антивирусом Avast.
> https://www.avast.com/antivirus
>
>
> ___
> 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@lists.scsys.co.uk
___
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@lists.scsys.co.uk

Re: [Dbix-class] Is this list dead?

[Karen Etheridge]

It's neither nice nor not nice -- it's just practical, since there are lots
of people that use irc every day and this channel does get a fair amount of
traffic with people asking questions.

If irc isn't your thing, please feel free to use the list instead.  But I
do encourage you to give irc a try as lots of interesting things happen
there :)


On Wed, Jul 8, 2020 at 7:14 AM Marco Vittorini Orgeas 
wrote:

> On 07/08/2020 02:46 PM, Veesh Goldman wrote:
>
> You can drop in in irc.perl.org #dbix-class and ask questions there. A
> lot of experts.
>
> Promoting a chat to get support on this list isn't that nice, nor
> recommended I'd add, considering that much of the information flowing on
> IRC is lost and is difficult to have an ongoing discussion with multiple
> parties there.
>
___
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@lists.scsys.co.uk

Re: [Dbix-class] Twitter accounts

[Karen Etheridge]

I can't vote as I don't have a twitter account.

I vote for the option where people can actually cooperate in a group where
$size > 1.

I think Jess deserves an apology here.  Reasonable communication could have
been had, but instead there was none, with the implication that she was
holding the account to ransom.

I am extremely disappointed in the "if I can't have full sole control of
everything, then I will hold the entire community hostage and make it seem
like it's everyone else's fault" attitude.  Being able to work with a group
is an important and necessary skill with open source.  It is a fallacy in
the extreme to assert that an account, or a project, would "wither" if all
other people would be removed from being able to contribute.


On Wed, Jan 31, 2018 at 11:22 AM, Peter Rabbitson 
wrote:

> On 01/31/2018 07:55 PM, Matt S Trout wrote:
>
>
>> 
>>
>> ... I would suggest that there are two easy possibilities to maintain
>> @dbix_class
>> as an all-community announce account while still allowing riba ...
>>
>>
> I am not sure which event(s) from roughly 2014-onwards leave anyone with
> the impression that I am in any way interested in any participation in
> anything that can be labeled as "all-community".
>
> As far as I am concerned there is no dispute nor a crisis here. I took the
> account onwards as to not have it wither like everything else. This has now
> been reverted. I have no interest in arguing one way or another any further
> ( as per the quoted tweet - there is no point ).
>
> Since you are reading this storm-in-a-cup distraction anyway: please vote
> at the linked poll whether you'd be interested in future
> twitter-announcements on various DBIC-and-related-stuff matters, or whether
> the tweet-craze has ran its course: https://twitter.com/ribasushi/
> status/958716479708463104
>
> Cheers, and apologies for once again bringing an mst to your INBOX :/
>
>
> ___
> 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@lists.scsys.co.uk
>
___
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@lists.scsys.co.uk

Re: [Dbix-class] Avé! Duci Novo, Similis Duci Seneci!*

[Karen Etheridge]

On Tue, Jan 23, 2018 at 6:59 AM, John SJ Anderson 
wrote:

>
> Could you please turn on issue submission (it seems to be disabled at the
> moment
> ​)
>

​Why? rt.cpan.org is better:
1. that's where all the existing bugs are, so to start creating new issues
in a new location is confusing and disruptive,
2. creating an issue on github requires one to register an account there,
which some perl users have clearly stated they do not want to do,
3. it is not possible to move github issues between queues, whereas RT
supports this as a core feature,
4. rt.cpan.org supports linking to rt.perl.org issues and vice versa.

I use github issues when I have to, but when I have a choice, I *always*
choose RT, even for distributions that I author and maintain solely on my
own.

But regardless of what is chosen, absolutely the canonical repository and
bug queue should be indicated in metadata so metacpan can provide the
appropriate links.
___
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@lists.scsys.co.uk

Re: [Dbix-class] VOTE: Relinquish firstcome rights to Peter Rabbitson

[Karen Etheridge]

I have questions, before I vote:

- Is there an official response from Peter Rabbitson regarding this
proposal?
- Is there an official response from the current comaint-bit holders (FREW,
ILMARI, JROBINSON, MSTROUT)?
- What would the upcoming development plans be if this vote failed?  If
this passed?


On Wed, Jan 17, 2018 at 4:48 AM, Matthew Phillips  wrote:

> Per the process, the proposal has now been turned to a vote.
>
> Cheers
>
>
> On Jan 17, 2018 7:21 AM, "Andrew Beverley"  wrote:
>
> On Tue, 16 Jan 2018 20:31:11 -0500 Matthew Phillips wrote:
> > After some internal communication with DBIC team members (which spurred
> the
> > bootstrap removal that passed today), I am sending in this proposal to
> > enact Andrew Beverley's 2016 proposal[1] to reestablish Peter Rabbitson's
> > FIRSTCOME rights and overall control of the DBIC project.
>
> [...]
>
> I second this proposal.
>
> Andy
>
> > [1] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/
> 012399.html
>
> ___
> 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@lists.scsys.co.uk
>
>
>
> ___
> 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@lists.scsys.co.uk
>
___
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@lists.scsys.co.uk

Re: [Dbix-class] PROPOSAL: merging Haarg's patch and making it easier to do simple merges / emergency fixes

[Karen Etheridge]

I vote yes on proposal 1 (https://github.com/dbsrgits/dbix-class/pull/114
should be merged), so long as (as discussed) the documentation is suitably
amended to allow such a merge.

I vote no on proposal 2, to allow immediate merge and release of "obvious"
changes.  I would be more likely to support this proposal if it was amended
to either allow immediate merges but not release, or only allow *trial*
(unindexed) releases. I feel to do an immediate non-trial release requires
more oversight at this point still.

On Fri, Jan 12, 2018 at 8:25 AM, John Napiorkowski 
wrote:

> Two proposals for the governing committee
>
> First proposal:
>
> Haarg proposed a small and obvious fix here => https://github.com/
> dbsrgits/dbix-class/pull/114
>
> I think it should be merged.
>
> Second proposal:
>
> Anyone with comaint or first come should be able to merge and release as
> needed trivial or obvious patches (such as the one Haag proposed),
> documentation improvements, or fixes required immediately because of
> security issues or problems with upstream dependencies.  In those cases we
> can allow to skip voting and merge / release code at once.
>
> Regards,
>
> John Napiorkowski
>
> ___
> 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@lists.scsys.co.uk
>
___
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@lists.scsys.co.uk

Re: [Dbix-class] VOTE: Removing bootstrap phase

[Karen Etheridge]

I vote yes to the proposal.

-et...@cpan.org

On Sat, Jan 13, 2018 at 1:16 PM, Darren Duncan 
wrote:

> I vote +1.
>
>
> ___
> 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@lists.scsys.co.uk
>
___
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@lists.scsys.co.uk

Re: [Dbix-class] View Definitions for non-virtual views

[Karen Etheridge]

If they were dumped as comments rather than strings, then there would be no
runtime impact, but you still get the documentation benefit.  I'd certainly
make use of such an option, as I sometimes perform a dump just to confirm
that there were no surprising side effects to a change I made, and do not
commit the output.

On Fri, Jul 21, 2017 at 3:14 PM, Francisco Obispo 
wrote:

>
>
> On 21 Jul 2017, at 12:33, Matt S Trout wrote:
>
> On Fri, Jul 21, 2017 at 10:44:55AM -0700, Francisco Obispo wrote:
>>
>>> I created an RT ticket (I don’t know if it’s the right place), to
>>> document this behavior which I believe is a bug:
>>>
>>> https://rt.cpan.org/Public/Bug/Display.html?id=122544
>>>
>>
>> dbicdump is part of DBIx::Class::Schema::Loader not DBIx::Class itself
>>
>>
> Yes, but wasn’t sure were to post the request.
>
>
> The result is that `.pm`’s derived from a view from `dbicdump` are
>>> larger than they need to be, inherently using more memory, and with
>>> no real good purpose. There should be an option to turn this
>>> behavior off.
>>>
>>
>> While I don't see any reason we wouldn't take a patch to supply such an
>> option, I confess to being surprised that this was noticeable - how did
>> you measure the memory usage with and without, and how big was the
>> difference?
>>
>>
> The diffs in git started getting very big all of the sudden, and in the
> company that I work, that started raising questions on the QA team, plus we
> have some areas where we have fairly large postgres views whose complexity
> is completely abstracted in a simple structure that has no interest to the
> ORM.
>
> Those fairly large views, force us to store the definition in RAM (as a
> perl string) now just for the sake of documentation, but in reality, at
> least in our system, is the wrong place to store the view definition. I
> don’t want to have to explain a more junior developer that the real view
> lives in SQL, and what lives in the .PM is just a snapshot of how it looked
> when the schema was dumped.
>
> I’m not saying it might not be useful for a lot of people, but for us is
> not and I would like to have a switch to turn it off if the desire is to
> leave it on by default, which again, I would advocate to do it the other
> way around.
>
> best regards,
>
>
>
>
> --
>> Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and
>> a clue
>>
>> http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_
>> mst/
>>
>> Email me now on mst (at) shadowcat.co.uk and let's chat about how our
>> CPAN
>> commercial support, training and consultancy packages could help your
>> team.
>>
>> ___
>> 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@lists.scsys.co.uk
>>
>
> ___
> 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@lists.scsys.co.uk
>
___
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@lists.scsys.co.uk

Re: [Dbix-class] Governance: Proposal A is adopted

[Karen Etheridge]

The exact vote count was 50-2-1. Here is the tally of votes:
https://gist.github.com/karenetheridge/dc2f217e5064e08b34c443fdb89b5ae0
___
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@lists.scsys.co.uk

Re: [Dbix-class] ★ VOTE NOW: DBIC Governance andNamespace Control ★

[Karen Etheridge]

Proposal A.
___
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@lists.scsys.co.uk

Re: [Dbix-class] Decision time: which fork inherits the existing DBIx::Class namespace

[Karen Etheridge]

Me too.

Since now we know that Peter has nothing more to add to the proposal, let's
get on with it.

On Sat, Dec 3, 2016 at 12:23 PM, Dave Cross  wrote:

> On 03/12/2016 08:36, Chisel wrote:
>
> Sorry, I'm just sick of all this , and want to move forward.
>>
>
> +1
>
> I'm already on record as supporting mst's community-lead version of the
> project. I thought we'd pretty much reached a concensus on that a month ago
> and I really don't understand why this is still dragging on.
>
> Dave...
>
>
> ___
> 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@lists.scsys.co.uk
>
___
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@lists.scsys.co.uk

Re: [Dbix-class] An answer and a question

[Karen Etheridge]

Happy [American] Thanksgiving!

On Mon, Nov 14, 2016 at 3:24 AM, Peter Rabbitson 
wrote:

> On 11/14/2016 06:11 AM, Darren Duncan wrote:
>
>>
>> I would be interested to see Peter address this, in particular, to
>> either affirm or deny etc that he emailed Mark in May, and what he
>> thinks he said.
>>
>
> I will most definitely do so, for the above and other claims wrt my
> character made earlier.
>
> Either by Wed/Thu this week, or worst case scenario by thanksgiving.
>
> I just returned home from a long business trip, hence the numerous delays.
>
> Stay tuned.
>
>
> ___
> 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@lists.scsys.co.uk
>
___
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@lists.scsys.co.uk

Re: [Dbix-class] Alternative proposals proposal

[Karen Etheridge]

I don't see how more people would either "dilute responsibility" nor
destabilize the team.  For example, consider the people who hold comaint on
the Moose namespace:

https://metacpan.org/author/DOY
https://metacpan.org/author/DROLSKY
https://metacpan.org/author/ETHER
https://metacpan.org/author/FLORA
https://metacpan.org/author/GRODITI
https://metacpan.org/author/HDP
https://metacpan.org/author/MSTROUT
https://metacpan.org/author/PERIGRIN
https://metacpan.org/author/SARTAK
https://metacpan.org/author/STEVAN

or Catalyst:

https://metacpan.org/author/AGRUNDMA
https://metacpan.org/author/APEIRON
https://metacpan.org/author/ARCANEZ
https://metacpan.org/author/BOBTFISH
https://metacpan.org/author/BRICAS
https://metacpan.org/author/DGL
https://metacpan.org/author/EDENC
https://metacpan.org/author/ELLIOTT
https://metacpan.org/author/ETHER
https://metacpan.org/author/FLORA
https://metacpan.org/author/FREW
https://metacpan.org/author/HAARG
https://metacpan.org/author/ILMARI
https://metacpan.org/author/JJNAPIORK
https://metacpan.org/author/JROCKWAY
https://metacpan.org/author/MITHALDU
https://metacpan.org/author/MRAMBERG
https://metacpan.org/author/MSTROUT
https://metacpan.org/author/PHAYLON
https://metacpan.org/author/RIBASUSHI
https://metacpan.org/author/SSCAFFIDI
https://metacpan.org/author/VANSTYN
https://metacpan.org/author/WSHELDAHL

Both of these projects have some authors who contribute frequently, and some
less frequently, but in both cases it is reassuring to know that there are
additional people waiting in the wings to step in should a crisis occur
(either of the "she's off her meds" sort or "she was hit by a bus" sort).

Further, I would point out that Matt is comaint of both of these projects,
and
has **added to** the stability of them through his presence and advice, not
detracted from it.

Besides, Matt has held comaint on DBIx::Class itself all this time and has
not
meddled with the direction set by its BDFL for years; why would this be
expected to change if the leadership changed?  I am baffled at how such a
thing
would be presumed.




On Thu, Oct 13, 2016 at 1:42 PM, Peter Rabbitson 
wrote:

> It was suggested elsewhere I am against any "core team" plan. This is
> entirely false.
>
> As an *EXAMPLE* (I have not spoken to either of the poor saps below), a
> team similar to that would get several +1's from me:
>
> https://metacpan.org/author/FREW
> https://metacpan.org/author/HAARG
> https://metacpan.org/author/ILMARI
>
> If the number "5" is magical in some way, and diluting responsibility
> further is desirable: destabilize it a bit more, e.g.
>
> https://metacpan.org/author/FREW
> https://metacpan.org/author/HAARG
> https://metacpan.org/author/ILMARI
> https://metacpan.org/author/JROBINSON
> https://metacpan.org/author/SYSPETE
>
> As a community you seem to want prioritization of stability. Then why
> aren't you clamoring for a team that *mostly* leans towards stability
> *naturally*? I do not understand why settle for an illusion of a working
> group fully controlled by someone who demonstrably optimizes, and went on
> record intending to continue optimizing for progress for the sake of
> progress.
>
>
> ___
> 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@lists.scsys.co.uk
>
___
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@lists.scsys.co.uk

Re: [Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Karen Etheridge]

On Sun, Oct 2, 2016 at 4:31 AM, Peter Rabbitson <ribasu...@cpan.org> wrote:
> I again must stress that there has been a huge 9+ months "discussion
> period" during which nobody (besides mst) came forward expressing
> concerns regarding my plans.

I had a lot of things to say, but I find that others have covered most of
the
main points, and I don't think I can say anything to persuade Peter away
from
the things he has already decided.  So, I will address my comments to the
PAUSE
admins instead:

1) I didn't think we were in a discussion period; I thought we were in a
period
of waiting for Peter to decide that he'd made all the changes he still
wanted
to make, so he would hand off control so that others could start submitting
change proposals again.

2) Once Peter had announced he was going to unilaterally hand off permission
bits to someone else, the slow-motion train wreck had already begun, but
since
the rest of the process was moving slowly, there seemed no pressing need to
act
immediately. Indeed, the more we waited, the more slowly things seemed to
progress.

3) Since I had contracted Peter (via my employer) for particular patches
last
year, I didn't want to say or do anything that would distract him or disrupt
that work, or become a conflict of interest with it; see also (2).

4) The length of time of Peter's involvement in the project, and the
intensity
and exclusivity thereof, entitles him to the gratitude from and
appreciation of
the community; it does not entitle him to unilaterally decide its future
direction.

5) Opening up control of the project (in the sense of having authority to
decide what is committed to the mainline code branch and released) to a
larger
number of people is in the best interests of all users, so long as that
group
is technically competent to do so and respects the critical nature of this
code.  The natural starting point for this group is the set of users who
currently have PAUSE permissions [1]; I trust this group collectively to
decide
who they wish to add to the group.  They also may wish to add additional
users
who can push commits to git (we found this to work well with Moose), but it
would also be reasonable to keep that locked down to the core group for now.

[1] Current PAUSE permissions on DBIx::Class are:

ABRAXXA (Alexander Hartmaier)
ARODLAND (Andrew Rodland; hobbs)
FREW (Arthur Axel "fREW" Schmidt)
ILMARI (Dagfinn Ilmari Mannsåker)
JROBINSON (Jess Robinson; castaway)
MSTROUT (Matt Trout; mst)
RIBASUSHI (Peter Rabbitson)


- Karen Etheridge, et...@cpan.org


On Mon, Oct 3, 2016 at 1:37 PM, David Golden <x...@xdg.me> wrote:

> Hello, DBIC community.
>
> I apologize in advance for the length of this email, but I urge everyone
> that uses DBIC to read it fully as it relates to the future of this
> important module.
>
> For those who don't know me, I'm DAGOLDEN on CPAN and I've joined this
> list in my capacity as a PAUSE <http://pause.perl.org> [1] administrator.
>
> For those on the list who aren't familiar with CPAN administration, PAUSE
> is the service that authors use to upload modules to CPAN.  Among other
> functions, it generates the index that maps modules names to downloadable
> tarballs – e.g. "DBIx::Class" to "RIBASUSHI/DBIx-Class-0.082840.tar.gz"
> on a CPAN mirror.
>
> PAUSE also maintains a permissions model
> <http://perladvent.org/2013/2013-12-08.html> [2] for each module
> namespace with two levels: "primary maintainer" (also called "first come")
> and "co-maintainer" (aka "co-maint").  Primary maintainers can grant and
> revoke co-maint permissions.  Both levels can upload tarballs to PAUSE,
> triggering an update to the index.
>
> Over the past several weeks, I've been the PAUSE administrator selected to
> mediate a dispute over future disposition of primary permissions for the
> DBIx::Class namespace.
>
> The dispute was triggered by Peter Rabbitson's "Traffic pattern changes
> ahead"
> <http://lists.scsys.co.uk/pipermail/dbix-class/2016-September/012187.html>
> [3] email to this list on September 6, in which he said:
>
> *I have also firmly selected who will be getting the DBIx::Class *
> *namespace first-come[2], the transfer of which will also happen *
> *somewhere around the end of September.*
>
> Because the identity of the new primary maintainer was neither disclosed
> nor discussed with Matt Trout (the founder of the DBIC project, current
> co-maintainer and also PAUSE administrator) or other co-maintainers,
> several private conversations between ensued between Matt, Peter and others
> about this declaration.
>
> On September 15, Peter notified PAUSE administrators via the
> modu...@perl.org mailing list of an "Upcoming PAUSE permissions dispute"
> <http://www.nntp.

Re: [Dbix-class] Joining the same table several times with different conditions each join

[Karen Etheridge]

On Sat, May 17, 2014 at 11:01:59AM +0100, Andrew Beverley wrote:
 I'd like to join the same table multiple times, with different
 conditions each join (and a variable number of joins).

If you define each of your join permutations as a relationship, you can
bring in the joins using that/those relationship name(s):

$rs-search({ ... }, { join = [ 'rel1', 'rel2', ... ] })

https://metacpan.org/pod/DBIx::Class::ResultSet#join

 Of course, the table could be designed with multiple columns for each of
 the values (surname and firstname being just 2 examples), but these are
 not known at the time of coding and are configurable by the application.

You can dynamically add relationship definitions at runtime.  Just keep the
rel names around in a local variable or attribute for later use.

Sorry if I am missing something complicated that would prevent this from
working -- as it seems pretty straightforward to me! :)



___
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@lists.scsys.co.uk

Re: [Dbix-class] Memory leak when connect string has utf8 flag set

[Karen Etheridge]

On Sun, Feb 16, 2014 at 01:31:51AM +0100, Roman Daniel wrote:
 Tracing some memory leak I found that my DBIC code leaks when the
 connection string is utf8 flagged.

This is my favourite go-to article for finding a leak:
http://blog.woobling.org/2009/05/become-hero-plumber.html

I've found several leaks from just Devel::Gladiator alone.

___
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@lists.scsys.co.uk

[Dbix-class] constructing a query where fields are compared to each other

[Karen Etheridge]

I'm trying to figure out how to construct a WHERE clause [1] like:

... WHERE field_x - field_y = 1

Is this possible?  The best guess I have is:

{ '1' = [ '-' = { -ident = 'field_x' },
  { -ident = 'field_y' }  ]  }

...but this expands to:
( 1 = ? OR 1 = me.field_x OR 1 = me.field_y )   with the bind variable 
being '-'.

The only operators that are covered in the SQL::Abstract docs are , , =
and !=, so are arithmetic operations even possible?

Since this is a pretty gross query regardless, I am leaning towards simply
adding a new column to this table, which is the value of field_x - field_y,
so I can query on that directly.


[1] I'm actually wanting to do this in a join relationship, so my real code
looks like the below - but I hope I've simplified adequately...

__PACKAGE__-has_many(cats_dogs = 'MyApp::Schema::Dogs' =
sub {
my $args = shift;
return +{
# foreign.field_x - foreign.field_y = 1
'1' = [ '-' = { -ident = $args-{foreign_alias}.field_x },
{ -ident = $args-{foreign_alias}.field_y }
}
},
);


thanks,
-et...@cpan.org

___
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@lists.scsys.co.uk

Re: [Dbix-class] constructing a query where fields are compared to each other

[Karen Etheridge]

On Wed, Oct 16, 2013 at 08:13:34PM -0400, Rob Kinyon wrote:
 It's good you showed all the code because the extended comparison in a
 join relationship isn't possible. (It's one of ribasushi's many
 in-progress branches. Patches most definitely welcome here.)
 
 However, this is definitely possible in a search. You have to use the 
 trapdoor.
 
 -search({ 1 = \me.field_x - me.field_y });
 
 That is a reference to a string.

A ha, so we drop down to literal SQL (via the scalar reference), but we
can't do that in a join because we can't jam the $args-{foreign_alias}
bits into the reference - it's then no longer literal SQL.

thanks!  looks like generating a new column to hold the value of the
arithmetic operation is indeed the right way to go (and I've already done
it, in the time it took for the mail to turn around). ;)


___
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@lists.scsys.co.uk