On 12/26/05 10:20 PM, Daniel Pittman wrote:
> The error I get on trying to load the object is:
>
> Cannot create method FooParent::child - method already exists at
> /usr/share/perl5/Rose/DB/Object/Metadata/MethodMaker.pm line 379
> [...]
> If anyone can point me to where I have gone wrong, or ev
On 12/27/05 8:22 AM, John Siracusa wrote:
> [a bunch of stuff that's not applicable to your situation]
Er, sorry about that. I misread your example. I'm in a rush this morning.
I'll look at it again later and post something that's actually correct... :)
-John
---
On 12/27/05 8:27 AM, John Siracusa wrote:
> On 12/27/05 8:22 AM, John Siracusa wrote:
>> [a bunch of stuff that's not applicable to your situation]
Actually, I was mostly right earlier. (No, really this time! :) You have a
conflict in your FooParent class between the foreign key and column names
In playing around with Rose::DB::Object, I have a question about the
Rose::DB derived object:
The examples for Rose::DB::Object all implement init_db like this:
sub init_db { return My::DB->new(); }
Now, so far as I can see that will create multiple My::DB (which isa
Rose::DB) instances, and
John Siracusa <[EMAIL PROTECTED]> writes:
> On 12/27/05 8:27 AM, John Siracusa wrote:
>> On 12/27/05 8:22 AM, John Siracusa wrote:
>>> [a bunch of stuff that's not applicable to your situation]
>
> Actually, I was mostly right earlier. (No, really this time! :) You have a
> conflict in your FooPa
On 12/27/05 8:11 PM, Daniel Pittman wrote:
> As I mentioned, I can't see why I would want to get the ID, rather than
> the object
There are a few reasons. The first, and most obvious, is that sometimes you
want the id and sometimes you want the thing it refers to. Maybe you never
needed the id,
On 12/27/05 8:44 PM, Daniel Pittman wrote:
> In playing around with Rose::DB::Object, I have a question about the
> Rose::DB derived object:
>
> The examples for Rose::DB::Object all implement init_db like this:
>
> sub init_db { return My::DB->new(); }
>
> Now, so far as I can see that will
To my great surprise, a 'varchar' column will truncate a long value if
the 'length' argument is supplied, rather than reject it.
This was rather unexpected to me, and I would much rather have the
system fault than silently truncate values, as that ensures that I don't
end up damaging data if I try
On 12/27/05 9:25 PM, Daniel Pittman wrote:
> To my great surprise, a 'varchar' column will truncate a long value if
> the 'length' argument is supplied, rather than reject it.
Yeah, some people want truncation, some want a warning, and some want a
fatal error. I should make this configurable. An
John Siracusa <[EMAIL PROTECTED]> writes:
> On 12/27/05 9:25 PM, Daniel Pittman wrote:
>> To my great surprise, a 'varchar' column will truncate a long value if
>> the 'length' argument is supplied, rather than reject it.
>
> Yeah, some people want truncation, some want a warning, and some want a
>
John Siracusa <[EMAIL PROTECTED]> writes:
> On 12/27/05 8:27 AM, John Siracusa wrote:
>> On 12/27/05 8:22 AM, John Siracusa wrote:
>>> [a bunch of stuff that's not applicable to your situation]
[...]
> Earlier, I suggested renaming your db columns, but that's actually a pretty
> extreme solution.
11 matches
Mail list logo