On Sep 28, 2006, at 8:17 PM, John Siracusa wrote:
> There are a lot more cases than you might think. Trying to
> correctly detect
> and handle those on a case-by-case basis is error-prone. Dividing all
> cached metadata by db neatly solves the problem at a relatively
> small cost.
good exp
On 9/28/06 7:45 PM, Jonathan Vanasco wrote:
> i found it odd how a lot of the data was cached as a per-db stash, the bulk
> of it seemed redundant. i imagine there are some edge cases where different
> DBs interact with the data in other ways.
There are a lot more cases than you might think. T
ok. a few hours of testing, and I've tracked all the issues down to
prime_caches and modperl
since I'm managing connections externally, and passing rose a DB
handle for every action, i had this:
__PACKAGE__->default_domain('NULL');
__PACKAGE__->default_type('NULL');
_
OK, following John's guidance, I have now set up a script that uses Loader
to create my table class modules in a directory outside of cgi-bin. John
explained that it's best to get Loader to put the files in a temporary area
and then copy them to where they need to go otherwise the existence of the
i just updated to the latest rosedb. i think i was at .742 before
none of my objects save now. they're all tossing me this error:
ERROR: null value in column "id" violates not-null constraint
I'm running PG, and all my tables have id as a serial ( not null ,
nextval(tablename_seq))
Hi,
On startup I'm getting a bunch of uninitialized value in hash element
warnings from Rose::DB::Object::Metadata lines 3752 and 3763.
Both lines have $self->{'dbi_requires_bind_param'}{$db->{'id'}}.
Everything works fine I just like a clean startup :)
Could it be that there is something that I
