binding variables to CASE WHEN

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

binding variables to CASE WHEN

Adam Witney
Hi,

I am trying to generate some counts in order to draw some charts. The query I have is this

SELECT TO_CHAR( collection_date, 'Mon' ) AS month,
       EXTRACT( year from collection_date ) AS year,
           COUNT( CASE WHEN pathogen.name = 'Staphylococcus epidermidis' THEN 1 ELSE NULL END ),
           COUNT( CASE WHEN pathogen.name = 'Staphylococcus hominis' THEN 1 ELSE NULL END )
   FROM
       culture me LEFT JOIN culture__pathogen culture_pathogens ON culture_pathogens.culture_id = me.id
                                  LEFT JOIN pathogen pathogen ON pathogen.id = culture_pathogens.pathogen_id
   GROUP BY year, month
   ORDER BY year, month

Which is generated from

$rs = $c->model('DB::Culture')->search( $search, {
        select => [
  { to_char => "collection_date, 'Mon'", -as => 'month' },
  { extract => "year from collection_date", -as => 'year' },
                { count => "CASE WHEN pathogen.name = '".$name1."' THEN 1 ELSE NULL END" },
                { count => "CASE WHEN pathogen.name = '".$name2."' THEN 1 ELSE NULL END" }
  ],
        join => { 'culture_pathogens' => 'pathogen'  },
        as => [ 'month','year', 'A', 'B' ],
        order_by => 'year, month',
        group_by => 'year, month'
});

But I need to bind values into the CASE WHEN statements. At the moment, presumably there is a possible SQL injection vulnerability?

Is it possible to bind variables into this?

Thanks

Adam

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: binding variables to CASE WHEN

Augustus Saunders

You can use literal SQL with bound parameters in most places. It's a reference to an array ref: \[SQL, bind1, bind2,...]. You can also put ? into your sql and pass a bind array explicitly in the attributes. It may take some experimentation to figure out what works, as there are bugs in the bind parameter handling. If all else fails, you can ask your database handle to quote your values to avoid SQL injection.

Augustus

On Apr 7, 2015, at 10:24 AM, Adam Witney <[hidden email]> wrote:

> Hi,
>
> I am trying to generate some counts in order to draw some charts. The query I have is this
>
> SELECT TO_CHAR( collection_date, 'Mon' ) AS month,
>       EXTRACT( year from collection_date ) AS year,
>   COUNT( CASE WHEN pathogen.name = 'Staphylococcus epidermidis' THEN 1 ELSE NULL END ),
>   COUNT( CASE WHEN pathogen.name = 'Staphylococcus hominis' THEN 1 ELSE NULL END )
>   FROM
>       culture me LEFT JOIN culture__pathogen culture_pathogens ON culture_pathogens.culture_id = me.id
>  LEFT JOIN pathogen pathogen ON pathogen.id = culture_pathogens.pathogen_id
>   GROUP BY year, month
>   ORDER BY year, month
>
> Which is generated from
>
> $rs = $c->model('DB::Culture')->search( $search, {
> select => [
>   { to_char => "collection_date, 'Mon'", -as => 'month' },
>   { extract => "year from collection_date", -as => 'year' },
> { count => "CASE WHEN pathogen.name = '".$name1."' THEN 1 ELSE NULL END" },
> { count => "CASE WHEN pathogen.name = '".$name2."' THEN 1 ELSE NULL END" }
>   ],
> join => { 'culture_pathogens' => 'pathogen'  },
> as => [ 'month','year', 'A', 'B' ],
> order_by => 'year, month',
> group_by => 'year, month'
> });
>
> But I need to bind values into the CASE WHEN statements. At the moment, presumably there is a possible SQL injection vulnerability?
>
> Is it possible to bind variables into this?
>
> Thanks
>
> Adam
>
> _______________________________________________
> 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@...


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: binding variables to CASE WHEN

Dagfinn Ilmari Mannsåker
Augustus Saunders <[hidden email]> writes:

> You can use literal SQL with bound parameters in most places. It's a
> reference to an array ref: \[SQL, bind1, bind2,...].

This shold work everywhere, and definitely works in select => [...].

> You can also put ? into your sql and pass a bind array explicitly in
> the attributes. It may take some experimentation to figure out what
> works, as there are bugs in the bind parameter handling.

Which bugs, specifically? Have you reported them?

> If all else fails, you can ask your database handle to quote your
> values to avoid SQL injection.
>
> Augustus
>
> On Apr 7, 2015, at 10:24 AM, Adam Witney <[hidden email]> wrote:
>
>> Hi,
>>
>> I am trying to generate some counts in order to draw some charts. The query I have is this
[…]
>> Which is generated from
>>
>> $rs = $c->model('DB::Culture')->search( $search, {
>> select => [
>>   { to_char => "collection_date, 'Mon'", -as => 'month' },
>>   { extract => "year from collection_date", -as => 'year' },
>> { count => "CASE WHEN pathogen.name = '".$name1."' THEN 1 ELSE NULL END" },
>> { count => "CASE WHEN pathogen.name = '".$name2."' THEN 1 ELSE NULL END" }

This will do what you want safely, using bind parameters:

    { count => \["CASE WHEN pathogen.name = ? THEN 1 ELSE NULL END", $name1] },

>>   ],
>> join => { 'culture_pathogens' => 'pathogen'  },
>> as => [ 'month','year', 'A', 'B' ],
>> order_by => 'year, month',
>> group_by => 'year, month'
>> });

Also, it's usually preferable to use

   columns  => { $dbic_alias => $sql_expr, … }

instead of

   select => [$sql_expr, …],
   as => [ $dbic_alias, … ],

as that makes it more obvious which SQL expression belongs to which
DBIC-side column name.

--
"I use RMS as a guide in the same way that a boat captain would use
 a lighthouse.  It's good to know where it is, but you generally
 don't want to find yourself in the same spot." - Tollef Fog Heen


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: binding variables to CASE WHEN

Augustus Saunders

On Apr 7, 2015, at 11:00 AM, Dagfinn Ilmari Mannsåker <[hidden email]> wrote:

> Augustus Saunders <[hidden email]> writes:
>
>> You can use literal SQL with bound parameters in most places. It's a
>> reference to an array ref: \[SQL, bind1, bind2,...].
>
> This shold work everywhere, and definitely works in select => [...].

Alas it does not work with key names, since they must be strings. If you need to bind parameters on the left hand side of the operator, you have to use ? or do the quoting manually.

>
>> You can also put ? into your sql and pass a bind array explicitly in
>> the attributes. It may take some experimentation to figure out what
>> works, as there are bugs in the bind parameter handling.
>
> Which bugs, specifically? Have you reported them?

Sorry, we haven't reported them yet. We're trying to prepare a patch for some other bugs, and I'm not sure if this was going to be covered or not. We are planning to fix the aliasing problems with count, but I'm not sure if we're fixing the bind problems with count. We also had bind problems with HAVING (separate from the counting bugs) but we're not sure if the problem is really with HAVING or mixing \[] and ?; it can't figure out what order to pass the bind parameters to DBI. At any rate, in our experience when you start doing more complicated things like the OP is doing, a little trial and error is required, and ultimately we had to manually quote some things.

Augustus
_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: binding variables to CASE WHEN

Adam Witney
In reply to this post by Dagfinn Ilmari Mannsåker

> This will do what you want safely, using bind parameters:
>
>     { count => \["CASE WHEN pathogen.name = ? THEN 1 ELSE NULL END",
> $name1] },

Thanks, this works perfectly
_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: binding variables to CASE WHEN

Dagfinn Ilmari Mannsåker
In reply to this post by Augustus Saunders
Augustus Saunders <[hidden email]> writes:

> On Apr 7, 2015, at 11:00 AM, Dagfinn Ilmari Mannsåker <[hidden email]> wrote:
>
>> Augustus Saunders <[hidden email]> writes:
>>
>>> You can use literal SQL with bound parameters in most places. It's a
>>> reference to an array ref: \[SQL, bind1, bind2,...].
>>
>> This shold work everywhere, and definitely works in select => [...].
>
> Alas it does not work with key names, since they must be strings. If
> you need to bind parameters on the left hand side of the operator, you
> have to use ? or do the quoting manually.

As explained in the Cookbook, you can pass the \[] directly to
->search(), or use { -and => [\[...], ...] } if you wish to combine it
with other conditions:

https://metacpan.org/pod/distribution/DBIx-Class/lib/DBIx/Class/Manual/Cookbook.pod#Using-SQL-functions-on-the-left-hand-side-of-a-comparison

When I said "doesn't work" I wasn't talking about situations wher perl
doesn't let you put a reference (e.g. hash keys), but places where DBIC
accepted it, but did the wrong thing.

>>> You can also put ? into your sql and pass a bind array explicitly in
>>> the attributes. It may take some experimentation to figure out what
>>> works, as there are bugs in the bind parameter handling.
>>
>> Which bugs, specifically? Have you reported them?
>
> Sorry, we haven't reported them yet. We're trying to prepare a patch
> for some other bugs, and I'm not sure if this was going to be covered
> or not. We are planning to fix the aliasing problems with count, but
> I'm not sure if we're fixing the bind problems with count. We also had
> bind problems with HAVING (separate from the counting bugs) but we're
> not sure if the problem is really with HAVING or mixing \[] and ?; it
> can't figure out what order to pass the bind parameters to DBI.

Could you please provide a minimal example where DBIC gets this wrong,
without waiting to come up with a patch?  A quick experiment with bind
parameters in all of GROUP_BY, HAVING and ORDER BY gets the order right
for me using DBIC version 0.082820.

Or are you talking about using \'' with placeholders and sticking the
parameters in the 'bind' attribute yourself?

> At any rate, in our experience when you start doing more complicated
> things like the OP is doing, a little trial and error is required, and
> ultimately we had to manually quote some things.

The things OP is doing with \[] is hardly complicated, and I'd be
_very_ surprised if anything went wrong there.

--
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: binding variables to CASE WHEN

Augustus Saunders

On Apr 8, 2015, at 5:03 AM, Dagfinn Ilmari Mannsåker <[hidden email]> wrote:

> As explained in the Cookbook, you can pass the \[] directly to
> ->search(), or use { -and => [\[...], ...] } if you wish to combine it
> with other conditions:
>
> https://metacpan.org/pod/distribution/DBIx-Class/lib/DBIx/Class/Manual/Cookbook.pod#Using-SQL-functions-on-the-left-hand-side-of-a-comparison

I would recommend that you don't refer people to that link, as that's generally speaking not how you want to accomplish that particular task.

> When I said "doesn't work" I wasn't talking about situations wher perl
> doesn't let you put a reference (e.g. hash keys), but places where DBIC
> accepted it, but did the wrong thing.

Let's say then that \[] is insufficient for all your variable binding needs due to Perl limitations.

> Could you please provide a minimal example where DBIC gets this wrong,
> without waiting to come up with a patch?  A quick experiment with bind
> parameters in all of GROUP_BY, HAVING and ORDER BY gets the order right
> for me using DBIC version 0.082820.
>
> Or are you talking about using \'' with placeholders and sticking the
> parameters in the 'bind' attribute yourself?

So count gets confused if you use bind => [] with your select clauses; it drops the select clauses but leaves the bind parameters in. Outside of count, here is an example that messes up:

          'attrs' => {
                       'select' => [
                                     \[
                                         'aggfunction(col, ?)',
                                         'somevar'
                                       ]
                                   ],
                       'group_by' => 'somecolumn1',
                       'having' => {
                                     '-and' => [
                                                 {
                                                   'aggfunction(col, ?)' => {'>' => '0'}
                                                 }
                                               ]
                                   }
                       'bind' => [
                                   'somevar'
                                 ],
                     },
          'where' => {
                       '-and' => [
                                   {
                                     'somecolumn2' => 1
                                   }
                                 ]
                     }

The 'somevar' that comes from bind => ['somevar'] is not being correctly lined up with the unbound ? from the having clause. At the DBI level we bind_param(1,somevar), bind_param(2, somevar), bind_param(3, 1), bind_param(4, 0), but the order should go somevar, 1, somevar, 0.

Thanks-
Augustus
_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: binding variables to CASE WHEN

Augustus Saunders

On Apr 8, 2015, at 12:13 PM, Peter Rabbitson <[hidden email]> wrote:

>> I would recommend that you don't refer people to that link, as that's generally speaking not how you want to accomplish that particular task.
>
> Please elaborate, also see below.

The example presents special casing a scenario that doesn't need it and is overly confusing for such a simple use case. It works, but {'column_expr' => $val}} or {'column_expr' => {op => $val}} is the more natural and obvious way to accomplish that task.

>> Let's say then that \[] is insufficient for all your variable binding needs due to Perl limitations.
>
> Let's elaborate on this? Going forward \[] is the only supported way of doing sql+bind passing, any issues with it need to be fixed.

I don't know that there are issues with \[], just as discussed Perl prevents us from using that everywhere we might want it. If DBIx could expose an alternate structure like:

{
        LHS => \[],
        op => whatever,
        RHS => \[]
}

that would work around the Perl limitation. But I think that's all handled by SQL::Abstract, so I'm not sure what's realistic here.

Also, we use bind in our codebase quite a bit, in particular with DBIx level views. I don't see an obvious way to eliminate that necessity. As we figure out how to use DBIx and SQL::Abstract better, we are reducing the need for custom SQL views, but there are still many SQL features unsupported by DBIx/SQL::Abstract that require this.

>> So count gets confused if you use bind => []
>
> Yes, because bind (the rs attribute) is nothing more of "Put these pieces *indiscriminately* before the FROM clause bind values". It is true this is not clearly documented, putting down a note to have an overhaul of this section.
>
> But the actual behavior is consistent with how bind[] was originally "designed" - i.e. it is an entirely stateless, low-level tool. This is why the \[] variant was devised and everything refers to it these days. Also note that if the patches you are working on alter the current behavior of the bind attribute it is exceedingly unlikely that I will be able to accept them.

I understand that you want people to use \[], but I am unclear on why you would not want bind to work correctly in the cases it is still required.

Thanks-
Augustus
_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: binding variables to CASE WHEN

Dagfinn Ilmari Mannsåker
In reply to this post by Augustus Saunders
Augustus Saunders <[hidden email]> writes:

> Outside of count, here is an example that messes up:
>
>     'attrs' => {
>       'select' => [
>                     \[
>                         'aggfunction(col, ?)',
>                         'somevar'
>                       ]
>                   ],
>       'group_by' => 'somecolumn1',
>       'having' => {
>         '-and' => [
>                     {
>                       'aggfunction(col, ?)' => {'>' => '0'}
>                     }
>                   ]
>       }
>       'bind' => [
>                   'somevar'
>                 ],
>     },
>     'where' => {
>       '-and' => [
>                   {
>                     'somecolumn2' => 1
>                   }
>                 ]
>     }
>
> The 'somevar' that comes from bind => ['somevar'] is not being
> correctly lined up with the unbound ? from the having clause. At the
> DBI level we bind_param(1,somevar), bind_param(2, somevar),
> bind_param(3, 1), bind_param(4, 0), but the order should go somevar,
> 1, somevar, 0.

Well, DBIC can't possibly know which part the bind parameter goes with,
so as Peter explained it just sticks it at the front.  Also, having an
expression on the LHS of the hash will break if you enable quote_names.
Instead, just do:

    having => \['aggfunction(col, ?) > ?', 'somevar', 0],

and it'll go in the right place reliably.

--
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
 the consequences of."                              -- Skud's Meta-Law


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: binding variables to CASE WHEN

Peter Rabbitson-2
On 04/08/2015 10:44 PM, Dagfinn Ilmari Mannsåker wrote:

> Augustus Saunders <[hidden email]> writes:
>
>> Outside of count, here is an example that messes up:
>>
>>      'attrs' => {
>>        'select' => [
>>                      \[
>>                          'aggfunction(col, ?)',
>>                          'somevar'
>>                        ]
>>                    ],
>>        'group_by' => 'somecolumn1',
>>        'having' => {
>>          '-and' => [
>>                      {
>>                        'aggfunction(col, ?)' => {'>' => '0'}
>>                      }
>>                    ]
>>        }
>>        'bind' => [
>>                    'somevar'
>>                  ],
>>      },
>>      'where' => {
>>        '-and' => [
>>                    {
>>                      'somecolumn2' => 1
>>                    }
>>                  ]
>>      }
>>
>> The 'somevar' that comes from bind => ['somevar'] is not being
>> correctly lined up with the unbound ? from the having clause. At the
>> DBI level we bind_param(1,somevar), bind_param(2, somevar),
>> bind_param(3, 1), bind_param(4, 0), but the order should go somevar,
>> 1, somevar, 0.
>
> Well, DBIC can't possibly know which part the bind parameter goes with,
> so as Peter explained it just sticks it at the front.

It's not even "in the front". It is specifically "in front of the FROM
bind stack". There is a separate SELECT bind stack (for 'select' =>
\['foo + ?', 42]) and even a pre-SELECT bind stack (for things like
https://metacpan.org/pod/DBIx::Class::SQLMaker::LimitDialects#SkipFirst)



_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: binding variables to CASE WHEN

Augustus Saunders
In reply to this post by Augustus Saunders

On Apr 8, 2015, at 1:47 PM, Peter Rabbitson <[hidden email]> wrote:

>> It works, but {'column_expr' => $val}} or {'column_expr' => {op => $val}} is the more natural and obvious way
>
> ... which however is a lie in terms of the API contract - you are telling DBIC "use the column named 'column_expr', nevermind the fact the column doesn't exist". Additionally you are relying on the side-effect of lack of quote_names, in which case most (but not all!) of the machinery does not check a column for existence.

We use this method all over the place, and it works great. Not everybody is going to read all the documentation, and if the obvious thing people try just works to solve their problem, you should probably consider mitigating whatever is bad about it--they're going to do it regardless. We have several DBIx developers here and we've all read substantial parts of the documentation and the source code, and I don't think any of us could tell you the potential pitfalls with this technique. We would be interested in understanding them, however, so we can help fix them or avoid them.

> So I could not disagree more with your statement "I would recommend that you don't refer people to that link". This is the one and only place people need to be pointed to when trying to do what the original poster asked.

On this one, I am actually the originator of the discussion. The link wasn't helpful for me, and I don't see it being helpful to others, which is why I recommended you don't reference it. If the obvious solution is bad (especially even though it works!) you should probably add an explanation there.

> "but this is ugly in perl" is not a valid argument to drive people away from the only universally correct solution. Please refrain from arguing this further in the context of new code.

I don't recall anybody talking about ugliness in Perl. However you should recognize that your "correct" solution has some deficiencies compared to the "obvious" solution. The mental burden of learning exceptional corner cases is real, but more importantly it pushes complexity into user code. It would add a significant amount of complexity to our code to handle simple columns and column expressions differently. We could of course never use {col => $val} and replace all usage with \[] constructs, but that makes query analysis harder since structural details have been moved inside a string.

It may be that \[] is correct in the general case (which for whatever reason doesn't apply to us) due to some technical limitation, but I think {col => $val} is better from a programmer standpoint. Perhaps the {RHS=>{}, op => whatever, RHS => {}} construct below can provide a mechanism that is technically safe in all scenarios while preserving the syntactic structure of the query. If the LHS is a hashref, then you could provide an actual AST-type structure for the column expression. Cleanly dealing with DISTINCT, ORDER BY, FILTER, OVER etc in aggregate/window functions without being forced to make string literals would be great.

>> If DBIx could expose an alternate structure like:
>>
>> {
>> LHS => \[],
>> op => whatever,
>> RHS => \[]
>> }
>>
>
> This has been proposed and couldn't be made to work consistently at the time. However the state of the art moved on, so it may be worth taking another look. Noted.

Cool. Thanks!

>> I understand that you want people to use \[], but I am unclear on why you would not want bind to work correctly in the cases it is still required.
>>
>
> It already works correctly... or am I misunderstanding the issue you are having...?
>
> Can you please make a small test case using as a model https://github.com/dbsrgits/dbix-class/blob/current/blead/t/count/group_by_func.t#L12-L21 
>
> Please do that *before* spending more time on attempting a fix as you see fit. Because if we do not agree on what needs fixing, your work will end up being discarded, which will be a shame.

As just one example, as far as I understand it, it is currently not possible to achieve LATERAL joins directly. Instead, you must create a view (the DBIx construct, ie virtual, not an actual DB level view). When you want to search on this view, you must pass bind variables for the ?s inside the view definition SQL.

Thanks-
Augustus


_______________________________________________
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@...
Loading...