is there a way to get Rose to search based on functions?
ie:
bad
SELECT * FROM useraccount WHERE email = ?
good
SELECT * FROM useraccount WHERE lower(email) = lower(?)
the second query will be optimized by the postgres planner to search
on this in
On 4/13/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> Catalyst does wrap the requests in eval, so if a controller dies you
> have to look for the exception stuffed int $c->errors somewhere
>
> If you don't mind doing a rollback on all requests then that sure
> makes things nice and simple. Thanks.
On Fri, Apr 13, 2007 at 07:40:04PM -0700, Bill Moseley wrote:
> This is still the current situation?:
>
> http://www.dev411.com/blog/2006/05/31/rose-db-object-aggregates
>
> i.e. Run you own SQL directly with DBI or use Views and a create a
> table (and manager) class for each one?
Perhaps
This is still the current situation?:
http://www.dev411.com/blog/2006/05/31/rose-db-object-aggregates
i.e. Run you own SQL directly with DBI or use Views and a create a
table (and manager) class for each one?
--
Bill Moseley
[EMAIL PROTECTED]
-
Uwe Voelker scribbled on 3/31/07 7:37 AM:
>
>> CPAN seems to have indexed all the example .pm files. If you (or some other
>> CPAN
>> expert) knows how to tell CPAN not to do that, please let me know. Perhaps
>> that
>> would reduce confusion while browsing the C::C::R package via browser.
On Fri, Apr 13, 2007 at 02:28:59PM -0400, Perrin Harkins wrote:
> On 4/13/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> > So, for example, in Catalyst in an end() (or something at the end) you
> > would look for errors and then do a rollback, otherwise commit? And
> > you look at AutoCommit to see
On 4/13/07, Derek Watson <[EMAIL PROTECTED]> wrote:
> Just wanted to chime in and mention that I'm using this as well. I
> prefer the Rose way of building queries to other modules that I have
> used in the past, such as SQL::Abstract.
Yikes, QueryBuilder was in no way meant as a general-purpose
re
On 4/13/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> So, for example, in Catalyst in an end() (or something at the end) you
> would look for errors and then do a rollback, otherwise commit? And
> you look at AutoCommit to see if you need to do either of those, I
> assume.
No, it's much simpler t
Just wanted to chime in and mention that I'm using this as well. I
prefer the Rose way of building queries to other modules that I have
used in the past, such as SQL::Abstract.
Any chance of getting support for HAVING to go along with GROUP BY?
Cheers,
On 3/27/07, John Siracusa <[EMAIL PROTECTE
On 4/13/07, Ovid <[EMAIL PROTECTED]> wrote:
> --- Bill Moseley <[EMAIL PROTECTED]> wrote:
>> I would expect that most applications need a shared dbh -- anything
>> that uses transactions, of course. And, therefore perhaps there was a
>> standard approach.
>
> You know, I was rather surprised about
On Apr 13, 2007, at 12:11 AM, Perrin Harkins wrote:
> My guess is that your code connects to the database from the parent
> process in order to do auto-discovery of the tables, and then you end
> up sharing the same handle when apache forks. Apache::DBI does
> prevent this, so you might consider
Perrin Harkins scribbled on 4/12/07 11:11 PM:
> On 4/12/07, Peter Karman <[EMAIL PROTECTED]> wrote:
>> here's my (admittedly buggy) code for doing this. It caches a single
>> dbh for
>> each unique RDB registry entry combination of domain.type.dsn. I know
>> that it
>> breaks under mod_perl --
--- Bill Moseley <[EMAIL PROTECTED]> wrote:
> I would expect that most applications need a shared dbh -- anything
> that uses transactions, of course. And, therefore perhaps there was a
> standard approach.
You know, I was rather surprised about that myself. I've heard so many
good things about
13 matches
Mail list logo
