On Feb 15, 2008 4:56 PM, John Siracusa [EMAIL PROTECTED] wrote:
* Added the forget_related() helper method.
This wasn't added to the :all export set in Rose::DB::Object:::Helpers.
Intentional?
-sam
-
This SF.net email
On Feb 17, 2008 3:36 PM, John Siracusa [EMAIL PROTECTED] wrote:
Maybe, but as I've said I'm not really a fan of runtime parameter
validation.
I'm a horrible typist which makes me a big fan.
Doing it in just one place may have a minimal impact, but
then the question becomes, why isn't it
Hey all. I'm working on adjusting to Rose from a long history with CDBI, so
I do this kind of thing a lot:
$foos = My::Foo::Manager-get_foos(bar = big);
When I really mean:
$foos = My::Foo::Manager-get_foos(query = [bar = big]);
This is a nasty bug since the first incorrect call doesn't
On Feb 12, 2008 4:18 PM, John Siracusa [EMAIL PROTECTED] wrote:
You need to strip() before freezing:
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Helpers.pm#strip
Thanks, that should help. Any reason you didn't just bake this into a
default Storbable freeze hook? If that
On Feb 12, 2008 2:51 PM, John Siracusa [EMAIL PROTECTED] wrote:
On Feb 12, 2008 2:28 PM, Sam Tregar [EMAIL PROTECTED] wrote:
But if I pass the object through Storable:
use Storable qw(freeze thaw);
my $foo = freeze($object);
my $obj = thaw($foo);
$obj
Hello all. I'm serializing some RDBO objects and it's causing some AUTOLOAD
confusion when I make a typo. For example, without Storable this code:
$object-some_method_that_doesnt_exist(foo);
Produces the expected error:
Can't locate object method some_method_that_doesnt_exist via package
Hey all. I'm working on migrating a Class::DBI system to RDBO and I'm
wondering how to implement temp columns. In CDBI these are accessors that
behave like normal column accessors but don't store data in the database.
Weird, but sometimes useful. Here's how they're setup in Class::DBI:
On Feb 1, 2008 5:50 PM, John Siracusa [EMAIL PROTECTED] wrote:
To make an object forget a previously fetched set, just set it to undef:
Cool, that works for me. Thanks!
-sam
-
This SF.net email is sponsored by: Microsoft
On Jan 31, 2008 3:53 PM, John Siracusa [EMAIL PROTECTED] wrote:
I'm assuming it only produces that error when it tries to emit the
Perl code for that class into a .pm file, right?
Yes, that's it. I was using the emitted Perl code to debug my auto-init
setup.
If so, I think I have the fix
On Jan 29, 2008 10:32 PM, John Siracusa [EMAIL PROTECTED] wrote:
On 1/29/08, Sam Tregar [EMAIL PROTECTED] wrote:
Do you happen to know if RDBO will tolerate a
DBIx::ContextualFetch based DBI handle?
It should, and if it doesn't, I can probably make it do so with some
minor edits. Give
On Jan 29, 2008 9:55 PM, Peter Karman [EMAIL PROTECTED] wrote:
just a naive guess here, but if you were using DBI-connect_cached as the
underlying connect method, wouldn't DBI handle the sharing for you?
No, I'm pretty sure DBI uses the class as part of the connect_cached key.
-sam
Hey all. I'm getting started with Rose::DB::Object. My problem is I need
to inter-operate with a large pre-existing Class::DBI code-base. I'd like
to setup Rose to be able to share the same DBI connection that Class::DBI
uses - otherwise I'll instantly double the number of connections from our
On Jan 29, 2008 10:06 PM, John Siracusa [EMAIL PROTECTED] wrote:
The db atribute of an RDBO-derived object isa Rose::DB, but each
Rose::DB-derived object has a DBI $dbh. IOW, plain old DBI database
handles are used via delegation in RDBO. There's no subclassing of
DBI classes at all.
13 matches
Mail list logo
