akagrawal3 has asked for the wisdom of the Perl Monks concerning the following question:

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re: MySQL undef
by marto (Cardinal) on Mar 04, 2012 at 12:48 UTC
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: MySQL undef
by erix (Prior) on Mar 04, 2012 at 12:38 UTC

    How can you ask such a question when nobody can possibly know what $aggr_table is? It /is/ not even a question. You should put some effort into posing a question, and explain what it is that you are trying to do, with what module, etc.

    (for example, read also this node: How do I post a question effectively? )

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: MySQL undef
by moritz (Cardinal) on Mar 04, 2012 at 13:20 UTC
    In DBIx::Class, the first argument to search are "normal" where conditions of an SQL clause, for example WHERE somerow > 0. If you don't have any such clauses, you can put an undef in the place. The second argument is for joins, groups and the like.

      Thank u moritz again. I am learning a lot from you :)
Re: MySQL undef
by TJPride (Pilgrim) on Mar 04, 2012 at 16:45 UTC
    If you're using MySQL, is there any particular reason why you need to abstract and make this unreadable?

    $query = ' SELECT span, MAX(ts) AS ts FROM my_table GROUP BY span';

    Takes like 15 seconds to type that, and it's far more intuitive.

      Agree. If a simple SQL query is what you are actually doing then just do that. Nothing could be easier to understand, debug or read. Yes there are places for DBIx and I have used it extensively, but trivial cases are not "it."