On 10/6/05, Uwe Voelker <[EMAIL PROTECTED]> wrote:
> And it would be possible to store the blob in the future in the
> filesystem and write a custom class which behaves like a RDBO class.
You could do it by making a new method type that loads from the file
system on demand, but that's about it. I
On 10/6/05, Uwe Voelker <[EMAIL PROTECTED]> wrote:
> Just for me to make it clear: If I run the same query first with
> require_objects and then with with_objects the number of (primary)
> objects returned by require_objects is always smaller or equal to
> with_objects? Because require_objects skip
In the specific case of a table with one big BLOB column, it's usually
more efficient to move the BLOBs to another table and then link to it
with a "one to one" relationship or foreign key. That will get you
the behavior you want, and will also probably be more efficient in the
database itself.
Yeah, but those are all implementation details, really. The
distinction as far as the API is concerned is that, if you use
require_objects, every object returned will have those sub-objects.
If you use with_objects, some might and some might not.
Just for me to make it clear: If I run the same
On 10/6/05, Uwe Voelker <[EMAIL PROTECTED]> wrote:
> Class::DBI has the concept of column groups (Primary, Essential, All).
>
> Is there a similar thing in RDBO? I would like to exclude some blobs
> from a table, which should only be loaded when explicitly called.
In order to add a generic column
On 10/6/05, Uwe Voelker <[EMAIL PROTECTED]> wrote:
>> I don't recall why I had that constraint in there, but I'm pretty sure
>> there was a good reason. I'll look into it.
>
> I just read your mail that you removed this constraint. But I'm curious:
> Did you find what the reason was? I'm intereste
Hello John,
Class::DBI has the concept of column groups (Primary, Essential, All).
Is there a similar thing in RDBO? I would like to exclude some blobs
from a table, which should only be loaded when explicitly called.
Thanks,
bye, Uwe
---
Hello John,
I don't recall why I had that constraint in there, but I'm pretty sure
there was a good reason. I'll look into it.
I just read your mail that you removed this constraint. But I'm curious:
Did you find what the reason was? I'm interested in it.
All that leaves is the "distinct"
On 10/6/05, John Siracusa <[EMAIL PROTECTED]> wrote:
> On 10/6/05, Uwe Voelker <[EMAIL PROTECTED]> wrote:
>> Currently RDBO allows only one table/relation via require_objects.
>
> I don't recall why I had that constraint in there, but I'm pretty sure
> there was a good reason. I'll look into it.
On 10/6/05, Uwe Voelker <[EMAIL PROTECTED]> wrote:
> Currently RDBO allows only one table/relation via require_objects.
I don't recall why I had that constraint in there, but I'm pretty sure
there was a good reason. I'll look into it.
> In my application I would need one 1:N and a prefetch (via
SELECT DISTINCT products.*
FROM products LEFT JOIN prices ON (products.id = prices.product_id)
WHERE prices.region = 'DE'
LIMIT 1, 1
I guess I'm wondering why require_objects isn't sufficient. IOW, is the
DISTINCT part important or is it the fact that only columns from products
are actually
On 10/6/05 4:13 AM, Uwe Voelker wrote:
>> But is there a way to do the following in RDBO:
>>
>> SELECT DISTINCT products.*
>> FROM products LEFT JOIN prices ON (products.id = prices.product_id)
>> WHERE prices.region = 'DE'
>> LIMIT 1, 1
>>
>> RDBO has no problems with the FROM and WHERE line, bu
Hello John,
thanks for the new release. Two annoying bugs in my application are gone.
The following important question is still open:
But is there a way to do the following in RDBO:
SELECT DISTINCT products.*
FROM products LEFT JOIN prices ON (products.id = prices.product_id)
WHERE prices.reg
13 matches
Mail list logo
