On 6/19/07, mla <[EMAIL PROTECTED]> wrote:
> Could you expand a bit on that first sentence? What's the purpose of the
> SQL abstraction?
It's to provide a structured, mutable representation of SQL, rather
than trying to deal with it as a big, opaque string.
> I wouldn't mind using SQL and then ju
John Siracusa wrote:
> On 6/19/07 9:59 PM, mla wrote:
>> Cool. Can I help? Do you already have a general approach in mind?
>
> The first step is to make a decent SQL abstract abstraction made up of
> mutable objects which link back to the relevant bits of RDBO metadata. I'll
> probably validate t
On 6/19/07 9:59 PM, mla wrote:
> Cool. Can I help? Do you already have a general approach in mind?
The first step is to make a decent SQL abstract abstraction made up of
mutable objects which link back to the relevant bits of RDBO metadata. I'll
probably validate that piece by re-implementing the
John Siracusa wrote:
> On 6/19/07, mla <[EMAIL PROTECTED]> wrote:
>> The features I'm interested in are:
>>
>>o Providing a somewhat consistent interface between these ad-hoc
>> result sets and normal RDBO objects.
>>
>>o Catching field typos which the accessors/mutators would give you
On 6/19/07, mla <[EMAIL PROTECTED]> wrote:
> The features I'm interested in are:
>
>o Providing a somewhat consistent interface between these ad-hoc
> result sets and normal RDBO objects.
>
>o Catching field typos which the accessors/mutators would give you.
> (although you could
I'm interested in doing complex joins with RDBO but
without having to map the results to specific Rose::DB::Object
classes.
I found a discussion along these lines from '05.
http://www.gossamer-threads.com/lists/catalyst/users/3095
excerpt:
"For funky SQL in the FROM clause or the column list,
