FAQ
Hi,

Is there any method in order to check if user session has expired, so that user is redirect to login page?
Something like $c->session->is_expired which returns true or false?

I've checked Catalyst Session Plugin, but I havem't found any method to check if session has expired.

David




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100415/c46114f3/attachment.htm

Search Discussions

  • Ben Hitz at Apr 15, 2010 at 4:59 pm
    $c->session->session_expires) returns 0 when the session is expired
    (and deletes the session).

    Caveat: I am brand new - never installed the sw, but I was JUST
    reading this in the docs.

    Ben
    On Apr 15, 2010, at 8:33 AM, David wrote:

    Hi,

    Is there any method in order to check if user session has expired,
    so that user is redirect to login page?
    Something like $c->session->is_expired which returns true or false?

    I've checked Catalyst Session Plugin, but I havem't found any method
    to check if session has expired.

    David


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    --
    Ben Hitz
    Senior Scientific Programmer ** Saccharomyces Genome Database ** GO
    Consortium
    Stanford University ** hitz@genome.stanford.edu
  • David at Apr 16, 2010 at 7:41 am
    Hi Ben,

    thanks! But I have tested it and, in fact, is $c->session_expires.
    $c->session->session_expires does not work at all.


    David




    ________________________________
    De: Ben Hitz <hitz@genome.stanford.edu>
    Para: The elegant MVC web framework <catalyst@lists.scsys.co.uk>
    Enviado: jue,15 abril, 2010 18:59
    Asunto: Re: [Catalyst] Check is session is expired

    $c->session->session_expires) returns 0 when the session is expired (and deletes the session).

    Caveat: I am brand new - never installed the sw, but I was JUST reading this in the docs.

    Ben
    On Apr 15, 2010, at 8:33 AM, David wrote:

    Hi,

    Is there any method in order to check if user session has expired, so that user is redirect to login page?
    Something like $c->session->is_expired which returns true or false?

    I've checked Catalyst Session Plugin, but I havem't found any method to check if session has expired.

    David


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    --
    Ben Hitz
    Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium
    Stanford University ** hitz@genome.stanford.edu




    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/




    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100416/fde8c215/attachment.htm
  • David at Apr 16, 2010 at 9:51 am
    Regarding session expiring, I am having a little problem.

    I want to redirecto to login page whenever session is expired. It works allright, but when I do the redirect in a Controller index method ( sub index :Path :Args(0){} ), I always get next error message:

    Caught exception in engine "Can't call method "as_string" on an undefined value at /usr/local/share/perl/5.8.8/Catalyst/Engine.pm line 95."
    Browser gets 404 HTTP Error, because instead of being redirect to login page, it is redirect to the same page, the page which is served int the index method.

    I have made tests, and the redirect doesn't seem to be working right in this case. Code is executed after redirect, instead of stopping executing.

    Redirect looks like: $c->response->redirect($c->uri_for('/'));


    David




    ________________________________
    De: Ben Hitz <hitz@genome.stanford.edu>
    Para: The elegant MVC web framework <catalyst@lists.scsys.co.uk>
    Enviado: jue,15 abril, 2010 18:59
    Asunto: Re: [Catalyst] Check is session is expired

    $c->session->session_expires) returns 0 when the session is expired (and deletes the session).

    Caveat: I am brand new - never installed the sw, but I was JUST reading this in the docs.

    Ben
    On Apr 15, 2010, at 8:33 AM, David wrote:

    Hi,

    Is there any method in order to check if user session has expired, so that user is redirect to login page?
    Something like $c->session->is_expired which returns true or false?

    I've checked Catalyst Session Plugin, but I havem't found any method to check if session has expired.

    David


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    --
    Ben Hitz
    Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium
    Stanford University ** hitz@genome.stanford.edu




    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/




    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100416/0d3b5e20/attachment.htm
  • Alexander Hartmaier at Apr 16, 2010 at 12:02 pm
    You have to $c->detach() right after the redirect to stop further
    execution of the current action.
    If you're doing the redirect in an auto method you might also return a
    false value.

    --
    Best regards, Alex


    Am Freitag, den 16.04.2010, 11:51 +0200 schrieb David:
    Regarding session expiring, I am having a little problem.

    I want to redirecto to login page whenever session is expired. It
    works allright, but when I do the redirect in a Controller index
    method ( sub index :Path :Args(0){} ), I always get next error
    message:

    Caught exception in engine "Can't call method "as_string" on an
    undefined value at /usr/local/share/perl/5.8.8/Catalyst/Engine.pm line
    95."
    Browser gets 404 HTTP Error, because instead of being redirect to
    login page, it is redirect to the same page, the page which is served
    int the index method.

    I have made tests, and the redirect doesn't seem to be working right
    in this case. Code is executed after redirect, instead of stopping
    executing.

    Redirect looks like: $c->response->redirect($c->uri_for('/'));


    David




    ______________________________________________________________________
    De: Ben Hitz <hitz@genome.stanford.edu>
    Para: The elegant MVC web framework <catalyst@lists.scsys.co.uk>
    Enviado: jue,15 abril, 2010 18:59
    Asunto: Re: [Catalyst] Check is session is expired

    $c->session->session_expires) returns 0 when the session is expired
    (and deletes the session).

    Caveat: I am brand new - never installed the sw, but I was JUST
    reading this in the docs.

    Ben
    On Apr 15, 2010, at 8:33 AM, David wrote:

    Hi,

    Is there any method in order to check if user session has expired,
    so that user is redirect to login page?
    Something like $c->session->is_expired which returns true or false?

    I've checked Catalyst Session Plugin, but I havem't found any method
    to check if session has expired.
    David


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    --
    Ben Hitz
    Senior Scientific Programmer ** Saccharomyces Genome Database ** GO
    Consortium
    Stanford University ** hitz@genome.stanford.edu




    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

    *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
    T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
    Handelsgericht Wien, FN 79340b
    *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
    Notice: This e-mail contains information that is confidential and may be privileged.
    If you are not the intended recipient, please notify the sender and then
    delete this e-mail immediately.
    *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
  • Jon at Apr 16, 2010 at 3:01 pm

    I have made tests, and the redirect doesn't seem to be working right in this
    case. Code is executed after redirect, instead of stopping executing.
    You probably want to take a look at the Redirect plugin,
    http://search.cpan.org/~shot/Catalyst-Plugin-Redirect-0.02/lib/Catalyst/Plugin/Redirect.pm

    - jon
  • John Karr at Apr 17, 2010 at 5:01 am
    I'm still learning Catalyst and find that I don't like DBIx. As a counter
    example I love Template Toolkit, for exactly the same reason I hate DBIx.
    With TT html is in html, while DBIx seperates the database from SQL, if I
    were capable of writing an ORM (which I am not) it would be much more like
    Template Toolkit. Also I'm primarily a sysadmin working on some volunteer
    programming projects while out of work, so even though it might well be
    worth coming to terms with DBIx if I did more development, crawling through
    DBI seems a more efficient way for me to get working code written.

    The alternatives I've been able to discover are DBI and RoseDB. Is there any
    case (given why I've already stated I dislike DBIx) for RoseDB, and are
    there any other alternatives that work well with Catalyst that I have not
    found?
  • Curtis "Ovid" Poe at Apr 17, 2010 at 6:17 am

    ----- Original Message ----
    From: John Karr <brainbuz@brainbuz.org>
    The alternatives I've been able to discover are DBI and RoseDB.
    Is there any
    case (given why I've already stated I dislike DBIx) for RoseDB,
    and are
    there any other alternatives that work well with Catalyst that I have
    not found?

    Given what you've described, perhaps you want to take a look at Fey::SQL:

    http://search.cpan.org/perldoc?Fey::SQL

    The related Fey::ORM can be used with Catalyst:

    http://search.cpan.org/perldoc?Fey::ORM::Manual::Intro

    Cheers,
    Ovid
  • Lyle at Apr 17, 2010 at 1:35 pm
    Personally I think DBIx::Class is the biggest load of crock out there.
    It's much slower, awkward to use, time consuming to learn, and as soon
    as you try to do some complicated queries you'll end up dropping it
    anyway. ORMs simply cannot work in the long run:-
    http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html

    I found SQL::DB recently, which looks interesting to me, but haven't had
    chance to work with it yet. It might be what you are looking for.


    Lyle

    John Karr wrote:
    I'm still learning Catalyst and find that I don't like DBIx. As a counter
    example I love Template Toolkit, for exactly the same reason I hate DBIx.
    With TT html is in html, while DBIx seperates the database from SQL, if I
    were capable of writing an ORM (which I am not) it would be much more like
    Template Toolkit. Also I'm primarily a sysadmin working on some volunteer
    programming projects while out of work, so even though it might well be
    worth coming to terms with DBIx if I did more development, crawling through
    DBI seems a more efficient way for me to get working code written.

    The alternatives I've been able to discover are DBI and RoseDB. Is there any
    case (given why I've already stated I dislike DBIx) for RoseDB, and are
    there any other alternatives that work well with Catalyst that I have not
    found?


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • John Karr at Apr 17, 2010 at 2:59 pm
    Thanks Lyle and Ovid for your responses, both SQL::DB and Fey::SQL look like
    saner approaches, and I will take them both for a test drive. I also liked
    the article Lyle referenced.

    -----Original Message-----
    From: Lyle
    Sent: Saturday, April 17, 2010 9:36 AM
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Alternatives to DBIx?

    Personally I think DBIx::Class is the biggest load of crock out there.
    It's much slower, awkward to use, time consuming to learn, and as soon
    as you try to do some complicated queries you'll end up dropping it
    anyway. ORMs simply cannot work in the long run:-
    http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vi
    etnam-of-computer-science.html

    I found SQL::DB recently, which looks interesting to me, but haven't had
    chance to work with it yet. It might be what you are looking for.


    Lyle

    Ovid Wrote:

    Given what you've described, perhaps you want to take a look at Fey::SQL:

    http://search.cpan.org/perldoc?Fey::SQL

    The related Fey::ORM can be used with Catalyst:

    http://search.cpan.org/perldoc?Fey::ORM::Manual::Intro


    John Karr wrote:
    I'm still learning Catalyst and find that I don't like DBIx. As a counter
    example I love Template Toolkit, for exactly the same reason I hate DBIx.
    With TT html is in html, while DBIx seperates the database from SQL, if I
    were capable of writing an ORM (which I am not) it would be much more like
    Template Toolkit. Also I'm primarily a sysadmin working on some volunteer
    programming projects while out of work, so even though it might well be
    worth coming to terms with DBIx if I did more development, crawling through
    DBI seems a more efficient way for me to get working code written.

    The alternatives I've been able to discover are DBI and RoseDB. Is there any
    case (given why I've already stated I dislike DBIx) for RoseDB, and are
    there any other alternatives that work well with Catalyst that I have not
    found?


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Ashley Pond V at Apr 17, 2010 at 3:56 pm

    On Apr 17, 2010, at 7:59 AM, John Karr wrote:
    Thanks Lyle and Ovid for your responses, both SQL::DB and Fey::SQL
    look like
    saner approaches, and I will take them both for a test drive. I also
    liked
    the article Lyle referenced.

    -----Original Message-----
    From: Lyle
    Sent: Saturday, April 17, 2010 9:36 AM
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Alternatives to DBIx?

    Personally I think DBIx::Class is the biggest load of crock out there.
    It's much slower, awkward to use, time consuming to learn, and as soon
    as you try to do some complicated queries you'll end up dropping it
    anyway. ORMs simply cannot work in the long run:-
    http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vi
    etnam-of-computer-science.html
    Just to put it out there -- I think for every dev who has arrived at
    this conclusion there are more who think DBIx::Class and Rose::DB and
    friends are wonderful.

    DBIC does have one caveat that can make it bad a choice: it requires
    some rigor in your database schema. Broken, bad, goofy DB
    relationships make DBIC a poor choice because you might have to
    resort to crazy code to make things work. If your schema is sane,
    everything, even extremely complicated queries are generally easy
    (after you get ramped up, it does have a learning curve).

    Of course you can use straight DBI etc and if it's what you're used to
    it will be much faster at first. The main issue is that you'll get
    templates or controllers littered with shims, iterators, raw SQL etc.
    You could of course start pushing it back into the model yourself but
    what that'll be doing is slowly reinventing one of the other ORMs but
    much less well.

    This is basically "every Perl developer has to write his own
    templating language once to learn why it's such a bad," part 2. You'll
    have to learn a lot either way. The Stone Soup of rolling it yourself
    is seductive and seems easier but taken as a whole it is most
    certainly not.

    -Ashley
  • Jay Shirley at Apr 17, 2010 at 3:32 pm

    On Sat, Apr 17, 2010 at 6:35 AM, Lyle wrote:
    Personally I think DBIx::Class is the biggest load of crock out there. It's
    much slower, awkward to use, time consuming to learn, and as soon as you try
    to do some complicated queries you'll end up dropping it anyway. ORMs simply
    cannot work in the long run:-
    http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html

    I found SQL::DB recently, which looks interesting to me, but haven't had
    chance to work with it yet. It might be what you are looking for.


    Lyle
    Way to be respectful of the hard work of other people, and the
    successes they've had.

    All your points are subjective and some are just wrong.

    It's much slower than what?
    Time consuming to learn? How's that? If you already know SQL, sure.
    If you don't, DBIC is probably much faster.
    Complicated Queries? Sorry, but I run *massively* complicated
    reporting queries (using custom result sources, no "real" objects) and
    it spits out a series of *very* advanced reports. It wasn't hard,
    took me about 2 hours to get that up and running.

    ORMs have their limitation, but to just attack a measurably successful
    project with baseless FUD is simply disrespectful.
  • Adam Sjøgren at Apr 17, 2010 at 5:09 pm

    On Sat, 17 Apr 2010 14:35:51 +0100, Lyle wrote:

    It's much slower, awkward to use, time consuming to learn, and as soon
    as you try to do some complicated queries you'll end up dropping it
    anyway.
    Ok, I'll bite: What system do you use instead of an object-relational mapper?


    Best regards,

    Adam, who, while curious, quite likes DBIx::Class; especially compared
    to other solutions I've tried.

    --
    "It's my chainsaw Adam Sj?gren
    Come see how it shines asjo@koldfront.dk
    I'm gonna cut out a living
    I'm gonna cut out your kind"
  • Lyle at Apr 17, 2010 at 6:15 pm

    Adam Sj?gren wrote:
    On Sat, 17 Apr 2010 14:35:51 +0100, Lyle wrote:

    It's much slower, awkward to use, time consuming to learn, and as soon
    as you try to do some complicated queries you'll end up dropping it
    anyway.
    Ok, I'll bite: What system do you use instead of an object-relational mapper?
    At the moment I just use DBI directly. Probably try DB::SQL next

    Everyone is entitled to their own opinion.


    Lyle
  • Adam Sjøgren at Apr 17, 2010 at 6:37 pm

    On Sat, 17 Apr 2010 19:15:14 +0100, Lyle wrote:

    Adam Sj?gren wrote:
    Ok, I'll bite: What system do you use instead of an object-relational mapper?
    At the moment I just use DBI directly.
    [...]

    Thanks for the answer.

    It is always nice to know what people like when they express contempt
    for other things. It gives you a chance to understand where they are
    coming from better.
    Everyone is entitled to their own opinion.
    Sure, but you can state your opinion in many ways. Some more conductive
    of a good, nuanced discussion, than others.


    Best regards,

    Adam

    --
    "I always liked songs with parentheses in the title." Adam Sj?gren
    asjo@koldfront.dk
  • Darren Duncan at Apr 17, 2010 at 8:02 pm

    Adam Sj?gren wrote:
    On Sat, 17 Apr 2010 19:15:14 +0100, Lyle wrote:
    Adam Sj?gren wrote:
    Ok, I'll bite: What system do you use instead of an object-relational mapper?
    At the moment I just use DBI directly.
    [...]

    Thanks for the answer.

    It is always nice to know what people like when they express contempt
    for other things. It gives you a chance to understand where they are
    coming from better.
    Personally, I prefer a middle-ground between raw DBI+SQL and ORMs as they are
    currently known, and that's what my Muldis D language and database toolkit is
    meant to deliver.

    People could treat it like a SQL templating system in the way that things like
    SQL::Abstract are treated, but that it is a lot more thorough in features and
    makes the SQL look more like Perl; your database tables are expressed as data
    type definitions plus declared variables of those types; your queries are
    expressed as mostly-declarational functions and procedures.

    You can write Muldis D either in string form like with SQL or Perl, which is
    better when you're writing code entirely manually, and you can write it as Perl
    data structures, which is better if you are generating code using Perl, both
    forms equally expressive; the latter is the closest analogy to traditional SQL
    generators.

    Muldis D is like a traditional ORM in that it has a variety of built-in features
    that SQL DBMSs in general lack, such as updateable views or collection-valued
    attributes, say to nest child records under parents.

    But unlike typical ORMs, it unifies objects and the relational model, and so
    considers that there is no impedence mismatch, while ORMs say there is a
    mismatch and tries to treat the two things as separate.

    In other words, Muldis D makes the database itself look more powerful or Perlish
    than it otherwise is, and so Perl programs can then use it as if it were just an
    ordinary programming language VM, based on types and routines like regular
    languages.

    I am perhaps a few days away from a milestone in this project and I wasn't going
    to talk about it here before that; but this thread sort of forced my hand as I
    didn't want the option to go unmentioned in it.

    -- Darren Duncan
  • Kiffin Gish at Apr 17, 2010 at 7:44 pm
    I'd say that rather than spending time studying SQL::DB, which I found
    complicated and hard to tackle, you might as well invest the same time
    and energy anyway in figuring out DBIx::Class.
    On Sat, 2010-04-17 at 14:35 +0100, Lyle wrote:
    Personally I think DBIx::Class is the biggest load of crock out there.
    It's much slower, awkward to use, time consuming to learn, and as soon
    as you try to do some complicated queries you'll end up dropping it
    anyway. ORMs simply cannot work in the long run:-
    http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html

    I found SQL::DB recently, which looks interesting to me, but haven't had
    chance to work with it yet. It might be what you are looking for.


    Lyle

    John Karr wrote:
    I'm still learning Catalyst and find that I don't like DBIx. As a counter
    example I love Template Toolkit, for exactly the same reason I hate DBIx.
    With TT html is in html, while DBIx seperates the database from SQL, if I
    were capable of writing an ORM (which I am not) it would be much more like
    Template Toolkit. Also I'm primarily a sysadmin working on some volunteer
    programming projects while out of work, so even though it might well be
    worth coming to terms with DBIx if I did more development, crawling through
    DBI seems a more efficient way for me to get working code written.

    The alternatives I've been able to discover are DBI and RoseDB. Is there any
    case (given why I've already stated I dislike DBIx) for RoseDB, and are
    there any other alternatives that work well with Catalyst that I have not
    found?


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

    --
    Kiffin Gish <Kiffin.Gish@planet.nl>
    Gouda, The Netherlands
  • Octavian Rasnita at Apr 17, 2010 at 7:57 pm
    From: "Kiffin Gish" <kiffin.gish@planet.nl>
    I'd say that rather than spending time studying SQL::DB, which I found
    complicated and hard to tackle, you might as well invest the same time
    and energy anyway in figuring out DBIx::Class.
    BTW, is there a comparison among the ORMs in Perl somewhere?
    It would be interesting and definitely helpful for the ORM newbies.

    Octavian
  • John Karr at Apr 17, 2010 at 11:04 pm
    I think there's a very important difference of approach, much as Template Tool Kit and Template Declare, radically different approaches, that are both far superior to the classic CGI Module.

    Working in raw DBI is the opposite of the DRY principle which underlies having a framework in the first place, so I am seeking an alternative. Just as Catalyst uses MVC, DBIx chooses ORM, but that paradigm is not the only way to be effective PERL<==>SQL glue. From the Manpage Fey::SQL looks like what I want: neatly wrapped and sweetened SQL, without the repetition and overhead inherent in working from DBI. I'm going to spend some time working with it and also with SQL::DB, when I have a more educated opinion I will share it. Both Fey and SQLDB are a nativist approach to SQL (much like TT is to html), and I would argue that in keeping the PERL paradigm of many ways to accomplish a task, the choice between a SQL-native DBI wrapper and an ORM wrapper should be up to the individual, the issue seems to be finding a worthy SQL-native wrapper.

    In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx.


    -----Original Message-----
    From: Octavian Rasnita
    Sent: Saturday, April 17, 2010 3:58 PM
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Alternatives to DBIx?

    From: "Kiffin Gish" <kiffin.gish@planet.nl>
    I'd say that rather than spending time studying SQL::DB, which I found
    complicated and hard to tackle, you might as well invest the same time
    and energy anyway in figuring out DBIx::Class.
    BTW, is there a comparison among the ORMs in Perl somewhere?
    It would be interesting and definitely helpful for the ORM newbies.

    Octavian


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Octavian Rasnita at Apr 17, 2010 at 11:35 pm
    Hi,

    From: "John Karr" <brainbuz@brainbuz.org>
    Working in raw DBI is the opposite of the DRY principle which underlies having a framework in the first place, so I am seeking an alternative.
    Just as Catalyst uses MVC, DBIx chooses ORM, but that paradigm is not the only way to be effective PERL<==>SQL glue. From the
    Manpage Fey::SQL looks like what I want: neatly wrapped and sweetened SQL, without the repetition and overhead inherent in working from > DBI. I'm going to spend some time working with it and also with SQL::DB, when I have a more educated opinion I will share it. Both Fey and
    SQLDB are a nativist approach to SQL (much like TT is to html), and I would argue that in keeping the PERL paradigm of many ways to
    accomplish a task, the choice between a SQL-native DBI wrapper and an ORM wrapper should be up to the individual, the issue seems to be > finding a worthy SQL-native wrapper.

    If the overhead/speed is the most important thing, then DBI is better than DBIC (by the way is DBIx::Class or DBIC, not just DBIx).

    But in that case you probably shouldn't be interested in using Template-Toolkit nor Catalyst, because they also have their overhead, and the other higher level modules used for accessing the database have their overhead also and the best solution would be DBI.
    In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested > on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx.
    Of course that an application that uses just mod_perl handlers and not very many objects, templates, form processors, ORMs... is faster than one that use them, and for someone who doesn't know the interface of those modules is also faster to develop because no aditional learning time is required, but that application will be much much harder to maintain on the long term.

    If the long term development process is important, then with very few exceptions, the applications should not be optimized prematurely because there may be found other more elegant optimizations than manipulating SQL code directly.

    Learning the interface of DBIC takes some time, but you shouldn't learn it again and again for each new project, so on the long term the development process will be much faster.

    If what you don't like at all is the DBIC syntax, then yes, in that case you have a good reason for using something else, but a good idea would be to learn it a little and try to use it in order to see its benefits.

    Octavian
  • Jay Shirley at Apr 17, 2010 at 11:39 pm

    On Sat, Apr 17, 2010 at 4:35 PM, Octavian Rasnita wrote:
    Hi,

    From: "John Karr" <brainbuz@brainbuz.org>
    Working in raw DBI is the opposite of the DRY principle which underlies having a framework in the first place, so I am seeking an alternative.
    Just as Catalyst uses MVC, DBIx chooses ORM, but that paradigm is not the only way to be effective PERL<==>SQL glue. From the
    Manpage Fey::SQL looks like what I want: neatly wrapped and sweetened SQL, without the repetition and overhead inherent in working from > DBI. I'm going to spend some time working with it and also with SQL::DB, when I have a more educated opinion I will share it. Both Fey and
    SQLDB are a nativist approach to SQL (much like TT is to html), and I would argue that in keeping the PERL paradigm of many ways to
    accomplish a task, the choice between a SQL-native DBI wrapper and an ORM wrapper should be up to the individual, the issue seems to be > finding a worthy SQL-native wrapper.

    If the overhead/speed is the most important thing, then DBI is better than DBIC (by the way is DBIx::Class or DBIC, not just DBIx).

    But in that case you probably shouldn't be interested in using Template-Toolkit nor Catalyst, because they also have their overhead, and the other higher level modules used for accessing the database have their overhead also and the best solution would be DBI.
    On the speed note, I have a harder time getting TT optimized than
    anything with DBIC. TT is almost always my bottleneck, and usually
    harder to cache.
  • Lyle at Apr 18, 2010 at 12:12 am

    Octavian Rasnita wrote:
    But in that case you probably shouldn't be interested in using
    Template-Toolkit nor Catalyst, because they also have their overhead,
    and the other higher level modules used for accessing the database
    have their overhead also and the best solution would be DBI.
    You've literally just spelled out why my preference is CGI::Application,
    HTML::Template and DBI. Not knocking Catalyst, I could see it's benefits.

    I guess it all depends on the what kind of websites you are working on,
    or what your customers expect.


    Lyle
  • Jay Shirley at Apr 18, 2010 at 12:44 am

    On Sat, Apr 17, 2010 at 5:12 PM, Lyle wrote:
    Octavian Rasnita wrote:
    But in that case you probably shouldn't be interested in using
    Template-Toolkit nor Catalyst, because they also have their overhead, and
    the other higher level modules used for accessing the database have their
    overhead also and the best solution would be DBI.
    You've literally just spelled out why my preference is CGI::Application,
    HTML::Template and DBI. Not knocking Catalyst, I could see it's benefits.

    I guess it all depends on the what kind of websites you are working on, or
    what your customers expect.
    Very true, which is why I use Catalyst and DBIC.

    I've had Catalyst+DBIC serving 10+ million hits a day. They expected
    fast performance, so I built and scaled accordingly. It worked
    beautiful.

    I've worked on some other high availability sites on Catalyst, with
    high traffic. Never had much of a problem getting good, quality
    results that have low deviation on performance.

    In addition, Catalyst being so flexible allows us to put in a great
    number of things with very little developer time -- hardware is much
    cheaper than a developer, and when you get to high end numbers that
    really adds up.

    If your developers cost less than your servers, raw DBI is probably a
    quite adequate solution. Glad someone is doing it, because I wouldn't
    touch those jobs.
  • Lyle at Apr 18, 2010 at 2:31 am

    J. Shirley wrote:
    If your developers cost less than your servers, raw DBI is probably a
    quite adequate solution. Glad someone is doing it, because I wouldn't
    touch those jobs
    All depends. If you're product is to go to hundreds of customers, then
    the cost of them all having to buy high end servers if much more than
    the developer time. Plus a lot of them won't buy if it means a server
    upgrade. Like I said it all depends on the what kind of websites you are
    working on, or what your customers expect. There are lots of different
    angles on these things.

    Don't get me wrong, when I free lance I have to do Cat/DBIC/Whatever,
    doesn't mean I enjoy or agree with it.


    Lyle
  • Ashley Pond V at Apr 18, 2010 at 3:33 am

    On Apr 17, 2010, at 7:31 PM, Lyle wrote:
    J. Shirley wrote:
    If your developers cost less than your servers, raw DBI is probably a
    quite adequate solution. Glad someone is doing it, because I
    wouldn't
    touch those jobs
    All depends. If you're product is to go to hundreds of customers,
    then the cost of them all having to buy high end servers if much
    more than the developer time. Plus a lot of them won't buy if it
    means a server upgrade. Like I said it all depends on the what kind
    of websites you are working on, or what your customers expect. There
    are lots of different angles on these things.

    Don't get me wrong, when I free lance I have to do Cat/DBIC/
    Whatever, doesn't mean I enjoy or agree with it.

    I have had several Cat apps on an $8/month host for several years now.
    Catalyst apps don't need high end (though they do usually need a
    persistent execution of some kind; modperl, fastcgi, etc; RoR and some
    PHP stuff having the same need has helped get fastcgi on many budget
    hosts). Just appending that to the thread for anyone who comes in to
    read this and gets the impression that anything else is true.

    -Ashley
  • Jay Shirley at Apr 17, 2010 at 11:36 pm

    On Sat, Apr 17, 2010 at 4:04 PM, John Karr wrote:
    I think there's a very important difference of approach, much as Template Tool Kit and Template Declare, radically different approaches, that are both far superior to the classic CGI Module.

    Working in raw DBI is the opposite of the DRY principle which underlies having a framework in the first place, so I am seeking an alternative. Just as Catalyst uses MVC, DBIx chooses ORM, but that paradigm is not the only way to be effective PERL<==>SQL glue. From the Manpage Fey::SQL looks like what I want: neatly wrapped and sweetened SQL, without the repetition and overhead inherent in working from DBI. I'm going to spend some time working with it and also with SQL::DB, when I have a more educated opinion I will share it. Both Fey and SQLDB are a nativist approach to SQL (much like TT is to html), and I would argue that in keeping the PERL paradigm of many ways to accomplish a task, the choice between a SQL-native DBI wrapper and an ORM wrapper should be up to the individual, the issue seems to be finding a worthy SQL-native wrapper.

    In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx.
    Please understand that DBIx means "Extensions to DBI", it does not
    mean DBIx::Class. This is abbreviated as "DBIC" but not "DBIx".
    There's a canned response to people who do this, but I'll save you
    that... if you look at
    http://search.cpan.org/search?mode=all&queryÛIx you'll see all the
    modules that have nothing to do with DBIx::Class that are listed
    there.

    I think Fey is a reasonable alternative if you aren't looking for the
    advanced features that DBIC gets you, but your general sentiment about
    the difference between an SQL API and an ORM is spot on.

    (Also, you may want to stick to writing Perl as "perl" is just as
    wrong as DBIC being called DBIx.)

    -J
  • Kevin montuori at Apr 17, 2010 at 11:38 pm

    On Sat, Apr 17, 2010 at 7:04 PM, John Karr wrote:

    In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx.

    I'm in no way arguing with your conclusion, such as it is; however,
    there's more to evaluate than just time spent learning a new library.
    In my experience (two or so years with DBIC/Catalyst and many, many
    more with sundry DBI hacks) DBIC code has proven trivial to maintain
    and augment. Furthermore, it's relatively easy to find programmers
    who are familiar with it and can be brought up to speed quickly. Your
    situation might be different; for me the maintenance is as important
    as the development.

    On a different note: I rarely have a need for raw SQL: what DBIC is
    generating is perfectly appropriate (and DBIC::Deploy does a bang-up
    job of creating DDL). When it is necessary, DBIC::ResultSource::View
    + native DB SQL code (stored procs, views, &c.) does a fine job of
    keeping SQL out of the Perl app. (I know that opinions on this differ
    -- ha! -- but it's worked out well for me, particularly when I hand an
    SP off to a DBA for optimization; as a rule I get less grief when it's
    just SQL and not SQL embedded in some other language.)

    k.

    --
    kevin montuori
  • Carl Johnstone at Apr 19, 2010 at 11:34 am

    kevin montuori wrote:
    In my experience (two or so years with DBIC/Catalyst and many, many
    more with sundry DBI hacks) DBIC code has proven trivial to maintain
    and augment. Furthermore, it's relatively easy to find programmers
    who are familiar with it and can be brought up to speed quickly. Your
    situation might be different; for me the maintenance is as important
    as the development.
    This.

    At $work we adopted DBIC around 3 years ago when we switched to Catalyst.
    Since then, whenever we've brought new people onto the team I've had plenty
    of discussions with them about how much DBIC gets in the way and they would
    be able to get stuff done quicker if we just allowed them to write the SQL
    queries.

    Eventually given enough experience with what we do, everybody comes around
    to seeing how much better things are with DBIC - especially when it comes to
    adding new features into the existing code base. I would say that DBIC
    actually becomes most useful when you stop thinking about SQL and start
    thinking in terms of the data that you actually need. Instead of trying to
    convert SQL to code, you just code and can be more productive.

    Carl
  • Peter Edwards at Apr 19, 2010 at 11:44 am

    kevin montuori wrote:
    In my experience (two or so years with DBIC/Catalyst and many, many
    more with sundry DBI hacks) DBIC code has proven trivial to maintain
    and augment. Furthermore, it's relatively easy to find programmers
    Exactly.

    Also I have an authz library that works against Oracle, Mysql and SQLite
    (and if I tried it, undoubtedly Postgresql too) without any trick code.

    DBIx::Class ++

    Regards, Peter
    http://perl.dragonstaff.co.uk
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100419/132110de/attachment.htm
  • Hakim Cassimally at Apr 19, 2010 at 11:59 am

    On 19 April 2010 12:34, Carl Johnstone wrote:
    kevin montuori wrote:
    DBIC code has proven trivial to maintain and augment.
    ...how much better things are with DBIC - especially when it comes to
    adding new features into the existing code base.
    Absolutely! When you are doing complicated reporting rollups
    (multiple joins, subqueries, aggregate functions) that can be
    arbitrarily tweaked, sorted, paged etc. then modifying with DBIC is
    often just a case of tweaking a single hash declaration...

    (Whereas updating a dynamic SQL codegen may well involve an hour of
    headscratching... Not to mention the other hour of debugging later,
    because you forgot to add a space or comma that kicks in with some
    rarely used set of parameters...)

    osfameron
  • John Karr at Apr 19, 2010 at 9:37 pm
    Most of the responses to this thread seem to say that DBIC is worth the
    effort. I looked at Fey:SQL and SQL::DB and concluded that they also require
    some effort, and suffer (along with DBIC) from what is for me a huge issue
    -- the documentation focuses on telling you how each piece works rather than
    on how to drive the darn thing.

    At this point for everything I'm working on, I have the luxury that I can
    write all of my joins and complex statements into a view or
    stored_procedure, but in the real world programmers are too frequently
    denied this, so even though right now I would like something that just
    wrapped the DBI up in a manner that made it easy to write and keep the DRY
    principle, it would be potentially more valuable to learn DBIC or Fey. DBIC
    is the more widely adapted solution, while Fey seems to offer most of the
    same capability with a syntax that draws on SQL (which is a lot of points in
    its' favor), but has less momentum and lacks equivalents of some of the
    helper scripts that are available for DBIC.

    So let me ask a follow up: What materials would you provide to an
    Intermediate Level Programmer to help them learn either Fey or DBIC?
    Materials could be working code, articles, things in documentation,
    documentation for other things that happens to explain it well, chapters in
    books, etc.

    Afternote. There is a "tutorial" in Fey::ORM's documentation, but it is more
    of a quick run-through. DBIx::Class has a better introduction in its'
    documentation, but that hasn't helped me much. The tutorial Kennedy Clark
    wrote for the Catalyst Manual was how I figured out Catalyst. Again
    developer isn't my normal job title, I will probably never get paid for
    knowing anything about ORM, time I spend learning it is only a benefit if it
    gives me pleasure (not so far) or saves me time in the long run (the clock
    is running the other way).


    -----Original Message-----
    From: Hakim Cassimally
    Sent: Monday, April 19, 2010 7:59 AM
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Alternatives to DBIx?
    On 19 April 2010 12:34, Carl Johnstone wrote:
    kevin montuori wrote:
    DBIC code has proven trivial to maintain and augment.
    ...how much better things are with DBIC - especially when it comes to
    adding new features into the existing code base.
    Absolutely! When you are doing complicated reporting rollups
    (multiple joins, subqueries, aggregate functions) that can be
    arbitrarily tweaked, sorted, paged etc. then modifying with DBIC is
    often just a case of tweaking a single hash declaration...

    (Whereas updating a dynamic SQL codegen may well involve an hour of
    headscratching... Not to mention the other hour of debugging later,
    because you forgot to add a space or comma that kicks in with some
    rarely used set of parameters...)

    osfameron

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Alex J. G. Burzyński at Apr 19, 2010 at 10:20 pm
    Hi,
    On 2010-04-19 22:37, John Karr wrote:
    Most of the responses to this thread seem to say that DBIC is worth the
    effort. I looked at Fey:SQL and SQL::DB and concluded that they also require
    some effort, and suffer (along with DBIC) from what is for me a huge issue
    -- the documentation focuses on telling you how each piece works rather than
    on how to drive the darn thing.

    At this point for everything I'm working on, I have the luxury that I can
    write all of my joins and complex statements into a view or
    stored_procedure, but in the real world programmers are too frequently
    denied this, so even though right now I would like something that just
    wrapped the DBI up in a manner that made it easy to write and keep the DRY
    principle, it would be potentially more valuable to learn DBIC or Fey. DBIC
    is the more widely adapted solution, while Fey seems to offer most of the
    same capability with a syntax that draws on SQL (which is a lot of points in
    its' favor), but has less momentum and lacks equivalents of some of the
    helper scripts that are available for DBIC.

    So let me ask a follow up: What materials would you provide to an
    Intermediate Level Programmer to help them learn either Fey or DBIC?
    Materials could be working code, articles, things in documentation,
    documentation for other things that happens to explain it well, chapters in
    books, etc.

    Afternote. There is a "tutorial" in Fey::ORM's documentation, but it is more
    of a quick run-through. DBIx::Class has a better introduction in its'
    documentation, but that hasn't helped me much. The tutorial Kennedy Clark
    wrote for the Catalyst Manual was how I figured out Catalyst. Again
    developer isn't my normal job title, I will probably never get paid for
    knowing anything about ORM, time I spend learning it is only a benefit if it
    gives me pleasure (not so far) or saves me time in the long run (the clock
    is running the other way).

    Since you've mentioned stored procedures I'm letting myself to mention
    DBIx::BlackBox.

    I've created it at $work to ease the integration of my Catalyst app with
    existing MS SQL database with hundreds of tables, views and stored
    procedures.

    The main driver was that I don't really want to learn all relationships
    between those tables + I've got very skilled DBA in my team who already
    knows this database :)

    So all those complex queries can happily live and be optimized at
    database level, while I can deal with data returned by those stored
    procedures.

    But I'm a huge fan of DBIx::Class and I can assure you that time spent
    on learning it won't be wasted, because maybe with your next job there
    won't be so complex queries and typing SELECT t1.col1, t2.col2 FROM tab1
    JOIN tab2 all over the place is just a waste of time if you can simply
    write $tab1->col1, $tab1->tab2->col2.

    Regarding documentation I've found DBIx::Class man pages good enough +
    most of the Catalyst examples/blogs are bundled with DBIC ones.

    Cheers,
    Alex
  • Peter Karman at Apr 20, 2010 at 1:05 am

    John Karr wrote on 4/19/10 4:37 PM:

    So let me ask a follow up: What materials would you provide to an
    Intermediate Level Programmer to help them learn either Fey or DBIC?
    Materials could be working code, articles, things in documentation,
    documentation for other things that happens to explain it well, chapters in
    books, etc.
    Rose::DB::Object (RDBO) hasn't been mentioned much in this thread. It has good
    manpage-type docs, and a decent intro tutorial:

    http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Tutorial.pod

    There is also Rose::DBx::Garden::Catalyst for bootstrapping an entire Cat app
    using RDBO:

    http://www.catalystframework.org/calendar/2007/7

    --
    Peter Karman . http://peknet.com/ . peter@peknet.com
  • Eden Cardim at Apr 18, 2010 at 5:14 am

    On Sat, Apr 17, 2010 at 8:04 PM, John Karr wrote:
    Both Fey and SQLDB are a nativist approach to SQL (much like TT is to html)
    TT isn't a native approach to html, by far. In fact, it has quite a
    few things going against it's use to generate html. Besides what
    jshirley already said, it doesn't produce streamable output and once
    your documents get complex, it's not very easy to produce nicely
    indented code with it. For a "native approach" to html, try
    HTML::Zoom.

    --
    Eden Cardim Need help with your Catalyst or DBIx::Class project?
    Code Monkey http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://edenc.vox.com/ http://www.shadowcat.co.uk/servers/
  • Andrew Rodland at Apr 18, 2010 at 6:38 am

    On Sunday, April 18, 2010 12:14:55 am Eden Cardim wrote:
    On Sat, Apr 17, 2010 at 8:04 PM, John Karr wrote:
    Both Fey and SQLDB are a nativist approach to SQL (much like TT is to
    html)
    TT isn't a native approach to html, by far. In fact, it has quite a
    few things going against it's use to generate html. Besides what
    jshirley already said, it doesn't produce streamable output and once
    your documents get complex, it's not very easy to produce nicely
    indented code with it. For a "native approach" to html, try
    HTML::Zoom.
    Very true. In fact, ignoring the fact that it ships with a couple default
    plugins that know how to do HTML-compatible string encoding, TT doesn't
    actually know anything about HTML. It's not actually an HTML tool at all; it's
    a tool for pasting strings together. It's entirely possible for those strings
    to be HTML tags, but since TT is agnostic, it's equally good at producing
    completely mangled, invalid HTML as it is at producing useful HTML (note: not
    a value judgment, just a simple fact!) If that's what "nativist" means, and
    you're looking for a tool that takes a string-schlepping approach to *SQL*,
    then you need look no further than a hundred thousand shitty PHP apps ;)

    Andrew
  • Andrew Rodland at Apr 18, 2010 at 6:34 am

    On Saturday, April 17, 2010 06:04:58 pm John Karr wrote:
    In my own analysis the Time and Effort to learn DBIx is greater than the
    Time wasted writing repetitious DBI code, the time I've already invested
    on DBIx has shown that there is a better way than DBI, but for me it isn't
    DBIx.
    In my own analysis the fact that you still think that there is a thing called
    DBIx proves that the time and effort you've spent learning _DBIC_ is zero.
  • Lyle at Apr 17, 2010 at 10:38 pm

    Kiffin Gish wrote:
    I'd say that rather than spending time studying SQL::DB, which I found
    complicated and hard to tackle, you might as well invest the same time
    and energy anyway in figuring out DBIx::Class.
    TBH if I really found the need for the DB to match up to objects, then
    I'd use an Object Database, not a Relational one. The only real argument
    for using a relational one instead, in that situation, is the
    performance benefits. When you want top performance from a relational
    database, you won't be using an ORM anyway.


    Lyle
  • Eden Cardim at Apr 18, 2010 at 5:00 am

    On Sat, Apr 17, 2010 at 7:38 PM, Lyle wrote:
    TBH if I really found the need for the DB to match up to objects, then I'd
    use an Object Database, not a Relational one. The only real argument for
    using a relational one instead, in that situation, is the performance
    benefits. When you want top performance from a relational database, you
    won't be using an ORM anyway.
    Actually, DBIx::Class, isn't necessarily an ORM, it's a Data Access
    Layer, given that inflation to objects is merely the default behaviour
    for it. You can very effortlessly coerce it to build an arbitrary data
    structure instead of objects from the data that's fetched from the
    database, and all the code up to the point where it inflates to
    objects is pretty much what you'd write if you used raw DBI anyway.
    Running arbitrary SQL is also very trivial to accomplish. In fact, I
    have a few projects where DBIx::Class is used solely as a query
    library and they all perform very well and were set up quite quickly,
    because I didn't have to spend time designing, building and testing an
    access layer.

    --
    Eden Cardim Need help with your Catalyst or DBIx::Class project?
    Code Monkey http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://edenc.vox.com/ http://www.shadowcat.co.uk/servers/
  • Marcello Romani at Apr 20, 2010 at 8:50 am

    Lyle ha scritto:
    Kiffin Gish wrote:
    I'd say that rather than spending time studying SQL::DB, which I found
    complicated and hard to tackle, you might as well invest the same time
    and energy anyway in figuring out DBIx::Class.
    TBH if I really found the need for the DB to match up to objects, then
    I'd use an Object Database, not a Relational one. The only real argument
    for using a relational one instead, in that situation, is the
    performance benefits. When you want top performance from a relational
    database, you won't be using an ORM anyway.
    But the question is: do you need raw dbi performance all over the place
    ? Just as you can write some critical functions in assembly and wrap
    them up in a C function or C++ class method, you can use an ORM to speed
    up development and have easier code maintenance, and use dbi+raw sql
    where you find a performance bottleneck.

    Also, as someone has mentioned earlier in this thread, DBIC requires a
    well-designed db schema, so in some way it prevents bad design decisions
    at the "raw-sql" level, thus helping to acheive good performance right
    from the start.

    Lyle


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

    Just my 2 (euro) cents.

    --
    Marcello Romani
  • Dami Laurent (PJ) at Apr 19, 2010 at 7:14 am

    -----Message d'origine-----
    De : John Karr
    Envoy? : samedi, 17. avril 2010 07:02
    ? : 'The elegant MVC web framework'
    Objet : [Catalyst] Alternatives to DBIx?
    The alternatives I've been able to discover are DBI and
    RoseDB. Is there any
    case (given why I've already stated I dislike DBIx) for RoseDB, and are
    there any other alternatives that work well with Catalyst that
    I have not
    found?
    One alternative that has not been mentioned so far is DBIx::DataModel.

    See
    http://search.cpan.org/~dami/DBIx-DataModel-1.24/lib/DBIx/DataModel.pm
    for SYNOPSIS,
    http://search.cpan.org/~dami/DBIx-DataModel-1.24/lib/DBIx/DataModel/Doc/Design.pod
    for design principles and some words about comparison to other ORMs, and
    http://search.cpan.org/~dami/DBIx-DataModel-1.24/lib/DBIx/DataModel/Doc/Reference.pod
    for complete reference.

    Enjoy, Laurent Dami

Related Discussions

People

Translate

site design / logo © 2022 Grokbase