[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 <francisco at obispo.link>
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 at 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 at lists.scsys.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20170721/ad82b969/attachment-0001.htm>