[RDBO] ANNOUNCE: This mailing list is moving to Google
As part of the migration from SourceForge to Google Code, The Rose::DB::Object mailing list is moving to a new address. All members of the old list (that is, the one you're reading right now) will be automatically unsubscribed and the list will (effectively) be closed some time this week. I've sent invitations to the new list to all current members of the old list. In case you didn't received that email, you can find out more about the new list here: http://groups.google.com/group/rose-db-object/about I believe you can read the list via the web or an RSS feed, in addition to (or instead of) email. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Migrating the wiki to Google Code
On Sat, Feb 23, 2008 at 8:08 PM, Derek Watson <[EMAIL PROTECTED]> wrote: > Please add [EMAIL PROTECTED] to the group! Done. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] ANNOUNCE: This mailing list is moving to Google
As part of the migration from SourceForge to Google Code, The Rose::DB::Object mailing list is moving to a new address. All members of the old list (that is, the one you're reading right now) will be automatically unsubscribed and the list will (effectively) be closed some time next week. I'm going to send invitations to the new list to all current members of the old list. In case you don't received that email, you can find out more about the new list here: http://groups.google.com/group/rose-db-object/about I believe you can read the list via the web or an RSS feed, in addition to (or instead of) email. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] Migrating the wiki to Google Code
The next step in the migration process from SourceForge to google Code is to move the wiki. I'm doing it slowly. If anyone else wants to help, just post your Google Account email address and I'll add you to the project. (Only project members can post to the wiki, which I hope will make it a lot more spam-proof.) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] SVN moved to Google Code
As the first step in the process of moving Rose from SourceForge to Google Code, the official SVN repository has moved to Google: https://rose.googlecode.com/svn/trunk You can find checkout instructions here: http://code.google.com/p/rose/source/checkout I've updated the wiki with the new URLs. All SVN committers, please email me your Google Account email address so I can get you set up for the new repository. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Hardcoded Carp::croak vs error_mode
On Thu, Feb 21, 2008 at 11:49 AM, John Ingram <[EMAIL PROTECTED]> wrote: > Well that's a different matter. I had tried that a while back and > found that the result was the same, which was what caused me to go > back to the default overflow behavior. Now that you refer me to that > spot in the code, I see that it calls croak() even when overflow is > set to 'warn'. Maybe that's supposed to be a carp(). Whoops, yep, it should be. Fixed in SVN now, thanks. > In any case, an option to non-fatally refuse to set the value might be > nice. Seems like handle_error() would do the trick. But like I > said, there must be some reason why handle_error() is not being used > there that I don't understand. The general rule is that handle_error() is reserved for handling database operations. Things that happen purely on the Perl side (e.g., setting column values, making methods, etc.) are considered on a case by case basis. I usually come down on the "fatal" side unless there's a compelling reason to do otherwise. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Hardcoded Carp::croak vs error_mode
On Thu, Feb 21, 2008 at 7:11 AM, John Ingram <[EMAIL PROTECTED]> wrote:
> The situation that I'm facing right now is when I set the value of a
> column to one longer than the column length, either through
> instantiation or the column's generated method:
>
> my $user = Foo::User->new( username => 'too_long_username');
>
> or...
>
> $user->username('too_long_username');
>
> Either one of those results in a croak().Seems to me that
> handle_error() is not inappropriate for that situation.
Just set the "overflow" property of the column to "warn" or "truncate"
to override teh default "fatal" mode:
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/MakeMethods/Generic.pm#overflow
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Hardcoded Carp::croak vs error_mode
On Wed, Feb 20, 2008 at 6:44 PM, John Ingram <[EMAIL PROTECTED]> wrote: > In the following packages: > > Rose::DB::Object::MakeMethods > Rose::DB::Object::MakeMethods::Generic > Rose::DB::Object::MakeMethods::DateTime > > ...I was surprised to find that $self->meta->handle_error is not being > used and there's a hardcoded Carp::croak instead. Is that > intentional? Am I missing something? I'm happy to make the change > and send the patch... just want to make sure I'm not missing a good > reason for it first. Exceptions are thrown unconditionally in situations that are beyond the bounds of "graceful" error handling. For example: Carp::croak "Error in generated code for method $name - [EMAIL PROTECTED]" When something like that happens, you need to know immediately :) If there are some specific cases of unconditional croak() that you think should be handled by meta->handle_error, list them so we can discuss them. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] RFC: Moving from SourceForge to Google Code
I've been considering moving the Rose project from SourceForge.net to code.google.com. My reasons: * I'm tried of wrangling with the wiki. With much more limited editing access, Google's wiki seems more bot-spam resistant. * SF.net always seems slow to me. Google's site seems faster. That's about it. I've not heard anything really bad about Google Code, but neither have I heard anything really good. Anyone have any opinions or experiences to share? -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] ANNOUNCE: Rose::DB::Object 0.767 released
On Feb 17, 2008 1:57 PM, Sam Tregar <[EMAIL PROTECTED]> wrote: > 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? No, just an oversight (though technically that export tag isn't even public, IIRC). Fixed in SVN now. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Manager quiet about bad syntax
On Feb 17, 2008 2:04 PM, Sam Tregar <[EMAIL PROTECTED]> wrote: > Params::Validate is pretty fast, in my experience. Could I win you over > with a patch and some benchmarks showing no significant performance > degradation? Maybe, but as I've said I'm not really a fan of runtime parameter validation. Doing it in just one place may have a minimal impact, but then the question becomes, why isn't it done everywhere? (Doing it everywhere adds significant overhead, both in terms of runtime cost and code bulk.) Do we add it on a per-request basis every time someone mistypes a parameter name? It's quite a sinkhole, IMO, which is why I do it nowhere: it's the egalitarian approach ;) > Speaking of, where would I get bench.pl from > http://rose.sourceforge.net/wiki/index.php/RDBO/Benchmark? It's included in the Rose::DB::Object distribution: http://search.cpan.org/src/JSIRACUSA/Rose-DB-Object-0.767/t/benchmarks/ -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] ANNOUNCE: Rose::DB::Object 0.767 released
Another release forced out due to bugs in the test suite. As usual, a few small features tagged along. New Rose::DB version required. -John Rose::DB::Object 0.767 (02.15.2008) - John Siracusa <[EMAIL PROTECTED]> * Added the forget_related() helper method. * Enhanced and documented the long-dormant "hints" Manager parameter. * Added a work-around for a DBD::Pg 2.0.0 array/bind_col() bug: http://rt.cpan.org//Ticket/Display.html?id=33193 * Improved the column method handling for array-reference values that may be fetched from array columns by DBD::Pg 2.0.0. * Fixed a bug in the test suite that caused some Postgres tests to fail if the "chkpass" column type was not installed. (Reported by Randal Schwartz) Rose::DB 0.740 (02.15.2008) - John Siracusa <[EMAIL PROTECTED]> * Added support for Rose::DB::Object 0.767's new hints features. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Manager quiet about bad syntax
On Thu, Feb 14, 2008 at 6:14 PM, Sam Tregar <[EMAIL PROTECTED]> wrote:
> 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 croak() - it just
> returns all the My::Foos! Sometimes I don't notice right away that I'm
> getting the wrong objects since my test set is small. Shouldn't it croak()?
Perl 5 doesn't have any language features for validating named
parameters, and doing so "manually" at runtime is (relatively)
expensive. This is especially true for Manager methods which take a
ton of parameters (and still growing).
As for your particular example, keep in mind that these are also equivalent:
$foos = My::Foo::Manager->get_foos([ bar => "big" ]);
$foos = My::Foo::Manager->get_foos({ bar => "big" });
(The first is preferred since the second is coerced into the first
internally.) You may find it easier to transition to these forms.
Finally, if you're really concerned, keep in mind that you can always
make your own Manager subclass that does check args, then have all
your real Manager classes inherit from it instead of inheriting form
Rose::DB::Object::Manager directly.
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] using MySQL's FOUND_ROWS() feature with QueryBuilder
On Thu, Feb 14, 2008 at 4:12 PM, Perrin Harkins <[EMAIL PROTECTED]> wrote: > On Thu, Feb 14, 2008 at 4:06 PM, Ken Prows <[EMAIL PROTECTED]> wrote: >> Sorry, I forgot to include the limit arg in my example. I do use limit so >> that I can page the data. I need to know the total matches so that I can >> determine how many pages there are. > > In that case, I recommend that you avoid FOUND_ROWS. It's almost > always worse than a second COUNT query. Try it in the mysql shell and > see. > > http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/ Not only that, but the number of rows is pretty meaningless if you're joining across any ...-to-many relationships (in which case what you really want is the count of the distinct rows from the primary table, which is what the Manager's *_count() method should give you). That said, there's been a "hints" API lurking in the Manager for a while now (since 2006 I think). I've gone ahead and documented and expanded it in SVN. You'll need both the SVN Rose::DB and Rose::DB::Object. https://rose.svn.sourceforge.net/svnroot/rose/trunk/modules/Rose-DB https://rose.svn.sourceforge.net/svnroot/rose/trunk/modules/Rose-DB-Object It's extremely limited and very MySQL-specific. It also avoids any direct injection of parameter values into the SQL string, though maybe I'll add such a thing at some point. Anyway, give it a spin. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Bizarre Side-Effect of Storable Use
On Feb 12, 2008 4:35 PM, Sam Tregar <[EMAIL PROTECTED]> wrote: > Thanks, that should help. Any reason you didn't just bake this into a > default Storbable freeze hook? As you can see from the docs, there are many decisions to be made about what, exactly, gets frozen, and there's no good way to communicate those decisions to a Storable hook routine, particularly on a per-call or per-object basis. (In the case of Rose::DB objects, things are simpler and I have standard Storable hooks there.) If you do decide to make some Storable hooks in your RDBO-derived base class, the existence of the independent strip() method should simplify things. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Bizarre Side-Effect of Storable Use
You need to strip() before freezing: http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Helpers.pm#strip Modifying your test: ... package My::Foo; use base 'My::DBObject'; use Rose::DB::Object::Helpers qw(strip); ... my $froze = freeze($foo->strip); -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Bizarre Side-Effect of Storable Use
On Feb 12, 2008 3:26 PM, Sam Tregar <[EMAIL PROTECTED]> wrote:
> Yes. I can whip up a simple test case if need be. Let me know if that
> would help.
Yes, that'd help because I can't reproduce it. I added a bit to
t/db-object-helpers.t to try:
$o = $class->new(id => 1)->load_or_save;
eval { $o->nonesuch };
print STDERR "Pre-freeze: [EMAIL PROTECTED]";
my $frozen = Storable::freeze($o->strip);
my $thawed = Storable::thaw($frozen);
is_deeply($thawed, $o, "strip 1 - $db_type");
eval { $thawed->nonesuch };
print STDERR "Post-freeze: [EMAIL PROTECTED]";
and I got the same error pre- and post-freeze: "Can't locate object
method "nonesuch" via package ..."
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Bizarre Side-Effect of Storable Use
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->some_method_that_doesnt_exist("foo");
>
> I get the completely nonsensical error:
>
> Can't store CODE items at ../../lib/Storable.pm (autosplit into
> ../../lib/auto/Storable/_freeze.al) line 287
Are you sure that error is generated by the
some_method_that_doesnt_exist() call and not the freeze() call?
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Odd Autoinitialization
On Feb 11, 2008 8:55 PM, Wiggins d'Anconia <[EMAIL PROTECTED]> wrote:
> my $test = $user->profile->user_agreement_accepted_on;
> warn "test: $test\n";
> unless (defined $test) {
> ...
> }
>
> Which results in 3 log lines,
>
> Use of uninitialized value in concatenation (.) or string at
> /.../C/User/Login.pm line 84. --- the warn line
> test:
> test: 2008-02-11T20:27:17
This double warn leads me to believe that something is going on that
is outside of your assumptions. I did a quick test of a class
fronting a Pg table with a timestamp column configured as you
described and got no spooky behavior.
So yes, please post a self-contained example that reproduces the bug.
I suggest you try to reproduce this behavior outside the web server
environment to eliminate (or perhaps pinpoint ;) that as the source of
the error.
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] ANNOUNCE: Rose::DB::Object 0.7665 released
Man, this seems to be the week for finding bugs that cause the test suite to fail, necessitating a new CPAN release to avoid the flood of CPAN tester failure reports. Here's one more, this one caused by the recent Rose::DB changes. The fix for Ben's auto_table_name() bug also comes along for the ride. 0.7665 (02.08.2008) - John Siracusa <[EMAIL PROTECTED]> * Fixed a bug that prevented the convention manager's auto_table_name() method from honoring the tables_are_singular() attribute value. (Reported by Ben Tilly) * The new, more correct behavior of Rose::DB 0.739's array column value parsing and formatting revealed a bug in QueryBuilder's handling of "(any|all)_in_array" conditions involving empty list arguments. This is now fixed. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] ANNOUNCE: Rose::DB 0.739
On Feb 8, 2008 2:44 PM, Perrin Harkins <[EMAIL PROTECTED]> wrote: > On Feb 8, 2008 1:43 PM, John Siracusa <[EMAIL PROTECTED]> wrote: > > * Caching of db objects during mod_perl server start-up is now turned > > off by default, with new API to turn it back on and do the necessary > > pre-fork clean-up that this entails. This change solved a > > segmentation > > fault problem triggered in DBD::Informix when database handles created > > in the parent were not properly disconnected prior to the first fork > > of > > the apache process. > > You will probably have to close the handles before forking, or at last > set InactiveDestroy, no matter which database you're using. Even if > you never use those handles again, they will eventually time out and > may break your new handles on the server side when they do. I've seen > this happen in forking code with MySQL handles. The previous code was just undef-ing the handles, which seemed to work fine for MySQL but caused DBD::Informix to segfault at or near the end of the lifetime for the apache child. (I set MaxRequestPerChild and and MaxClients to 1 to reproduce it without requiring many thousands of requests.) Anyway, the new code is not Informix-specific at all. It applies to all databases. I was just noting the original issue that led to the fix, in case other people with Informix run into it too. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] ANNOUNCE: Rose::DB 0.739
That's right, Rose::DB, not Rose::DB::Object. This change is important enough to go out on its own instead of waiting to be tied to a Rose::DB::Object release. 0.739 (02.08.2008) - John Siracusa <[EMAIL PROTECTED]> * Caching of db objects during mod_perl server start-up is now turned off by default, with new API to turn it back on and do the necessary pre-fork clean-up that this entails. This change solved a segmentation fault problem triggered in DBD::Informix when database handles created in the parent were not properly disconnected prior to the first fork of the apache process. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Having trouble making tables_are_singular work
On 2/6/08 5:12 PM, Ben Tilly wrote:
> Here is some non-working code:
>
> my $class = "ReportHistory::Installation";
> no strict 'refs';
> @{"$class\::ISA"} = 'ReportHistory::Object';
>
> $class->meta->convention_manager->tables_are_singular(1);
> $class->meta->auto_initialize();
> print $class->meta->perl_class_definition(indent => 2);
>
> This gives me an error because it can't find the table installations.
> But didn't I just tell it that tables are singular? I can get around
> this by setting the table name explicitly, but I'd like to know why
> the above didn't work.
You did everything right. It was a bug, fixed now in SVN. Thanks for the
report.
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] RDBO equivalent of Class::DBI's temp columns?
On Feb 6, 2008 3:18 PM, Sam Tregar <[EMAIL PROTECTED]> wrote: > 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: > > __PACKAGE__->columns(TEMP => qw/foo bar baz/); > > Is there a RDBO equivalent? If you just want simple scalar object attribute accessors, they're easy enough to make with your favorite method-maker. Here's an example using the Rose::Object scalar method-maker: http://www.mail-archive.com/rose-db-object@lists.sourceforge.net/msg01608.html If you want these "fake" columns to behave like RDBO columns in terms of parsing values according to the (fake) column data type, that's also possible if you call the appropriate Rose::DB::Object::MakeMethods::* method-maker methods directly, but it's a pain to have to look up the correct classes, methods, and args. So far in my work, I have not come across a need for such a thing and have gotten by using Rose::Object's simple method-maker to add non-db object attributes. But it'd be a good exercise in learning how RDBO's method-maker infrastructure works for someone to automate this into a proper column-data-type-aware "fake (or temporary, if you wish) column" API :) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] ANNOUNCE: Rose::DB::Object 0.7664 released
Corrected a bad skip count that caused 0.7663 to appear to fail one of its tests, and added a small fix and a small feature. 0.7664 (02.06.2008) - John Siracusa <[EMAIL PROTECTED]> * Fixed a bug that caused boolean columns to be incorrectly marked as modified. (Reported by Grzegorz Nosek) * Added sql_qualify_column_names_on_load() Metadata method to help support Postgres functions that can masquerade as columns if they're prefixed by the table name. (Suggested by Grzegorz Nosek) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] RDBO and computed columns
On Feb 5, 2008 5:16 PM, Grzegorz Nosek <[EMAIL PROTECTED]> wrote: > Hmm, I might be missing something, but inside the > sql_qualify_columns_on_load method you're using $_[1] after shifting > $self off the argument array, so to set the value to true, I must pass > two arguments to the method Too slow again: also fixed in SVN before you posted :) > OK, so I'll wait before upgrading my production version. BTW, I set up > postgres credentials so that 'make test' can use them and got failures > on the new tests (stderr output attached). That too. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] RDBO and computed columns
On Feb 5, 2008 4:06 PM, Grzegorz Nosek <[EMAIL PROTECTED]> wrote:
> t/db-objectok 1/566# Looks like you planned 566
> tests but only ran 562.
Whoops, that should be fixed now.
> sql_qualify_columns_on_load is on by default. Actually, it looks
> hardcoded to one ($self->{...} || 1 will always be true). I assume
> that's for testing
Yes, it's just for testing. It will be off by default (as per the docs :)
> Are you releasing a new version soon?
Probably tomorrow, after some more testing.
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] ANNOUNCE: Rose::DB::Object 0.7663 released
On Feb 5, 2008 3:25 AM, Michael Lackhoff <[EMAIL PROTECTED]> wrote: > I get this test failure with 0.7663: Yeah, there's a bad skip count in one of the tests. I've revoked 0.7663. Expect 0.7664 soon(ish) :) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] RDBO and computed columns
On Feb 4, 2008 3:51 PM, Grzegorz Nosek <[EMAIL PROTECTED]> wrote: > Test case attached. It's weird. Help! ;) Not so weird: it was a simple bug in the boolean method maker. It's fixed in SVN now. I'll work on the column name qualification option. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] RDBO and computed columns
On Feb 4, 2008 4:05 PM, John Siracusa <[EMAIL PROTECTED]> wrote: > On Feb 4, 2008 3:51 PM, Grzegorz Nosek <[EMAIL PROTECTED]> wrote: > > Functions taking rows as arguments may be used like extra table columns > > only when qualified with a table alias. > > Can you use an alternate "normal" function call form as well? > > SELECT id, ..., is_even(...) FROM test; > > I'm not sure what'd go in (...), however. Anyway, is there a syntax > form like that? It looks like this works: SELECT id, val1, val2, is_even(test) FROM test; In which case you can try making a custom column type as per: http://www.mail-archive.com/rose-db-object@lists.sourceforge.net/msg00710.html ...although I think it'll be kind of ugly since the table name will need to appear in there. It's also not a flexible as having it "just work" as a normal column specifier, so I'll see what I can do about adding an option to unconditionally qualify columns in single-object, single-table load() queries. (still working on the column modification thing...) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] RDBO and computed columns
On Feb 4, 2008 3:51 PM, Grzegorz Nosek <[EMAIL PROTECTED]> wrote: > Functions taking rows as arguments may be used like extra table columns > only when qualified with a table alias. Can you use an alternate "normal" function call form as well? SELECT id, ..., is_even(...) FROM test; I'm not sure what'd go in (...), however. Anyway, is there a syntax form like that? > BTW, I noticed that 0.7662 qualifies column names in ORDER BY clauses. > Nice :) That fixed another problem of mine, too (allows sorting on > function columns). Yeah, and around 0.765 all tables in Manager queries got unconditional qualifiers too. (haven't looked at your example yet) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] ANNOUNCE: Rose::DB::Object 0.7663 released
More bug fixes that I didn't want to wait until the next major release. -John 0.7663 (02.04.2008) - John Siracusa <[EMAIL PROTECTED]> * Fixed a bug that caused delete_on_save method creation for foreign keys to fail in some circumstances. (Reported by Justin Ellison) * Fixed a bug that prevented Perl code from being emitted for non-set columns with check_in attributes. (Reported by Sam Tregar) * Pushed cache control methods down into Rose::DB::Object::Cached in preparation for more caching subclasses. * The clear_object_cache() method now correctly clears load timestamps as well. (Patch by Justin Ellison) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] RDBO and computed columns
On Feb 3, 2008 5:07 PM, Grzegorz Nosek <[EMAIL PROTECTED]> wrote:
> __PACKAGE__
> ->meta->column('is_even')
> ->add_trigger('on_set',
> sub {
> unset_column_value_modified( $_[0], 'is_even' )
> });
>
> R::DB::O::Util is imported earlier with :columns
>
> But unfortunately, no go (no observable change in behaviour). Is this the
> right way to set up the trigger? After sticking a die in the callback
> the code survived too.
Sorry, actually I should have suggested on_load, but no matter because
something else is obviously wrong. Can you post a small
self-contained example including the table definitions and class
definitions? That's usually the fastest way to get to the bottom of
these things.
> BTW, below is the patch I'm using. If you could have a look at it and
> check for obvious blunders, I'd be very grateful. I'm including it for
> the off chance that I broke something by using it.
That's another thing: why is the table prefix necessary even on
single-table queries? I suspect the aforementioned self-contained
example will illuminate this as well, once I try to run it.
As for the patch, it looks reasonable but I'd rather understand why
it's necessary and provide official support for it than encourage you
to continue using your patch :)
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] RDBO and computed columns
On Feb 3, 2008 3:59 PM, Grzegorz Nosek <[EMAIL PROTECTED]> wrote:
> However, the problem arises after calling:
>
> my ($a_foo) = @{ Foo::Manager->get_objects( query => [ id => 5, is_even => 0
> ] ) };
> $a_foo->v2( 5 );
> $a_foo->save( changes_only => 1 );
>
> The is_even condition is a result of my condition builder (e.g. a user
> may access any foo as long as its value is even). The rather weird call
> to a manager method to get one item is its artefact too.
>
> After executing the above snippet, RDBO wants to update the is_even
> column and gets barfed at by PostgreSQL (there's no is_even column).
One quick fix might be to convince RDBO that the column is not
modified, perhaps by adding an on_set trigger to that "fake" is_even
column that uses the unset_column_value_modified() utility function:
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Util.pm#unset_column_value_modified
> Apparently the setter for the is_even column is called within the
> get_objects function, but AIUI, this shouldn't result in marking the
> column modified.
That may be a bug, but...
> I'm using RDBO v.0.763.
...I suggest getting the latest RDBO and then report back if the
Manager call still results in an object whose is_even column is marked
as modified. (And even if it's still a problem, you should consider
upgrading anyway. Many important bugs have been fixed between 0.763
and now :)
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Stale results from relationship accessors
On Feb 1, 2008 4:49 PM, Sam Tregar <[EMAIL PROTECTED]> wrote: > But without the reload subscribed_lists() keeps returning the old list. Is > there a way to tip off Rose that any cached lists for a particular > relationship are stale? Or something I'm doing wrong? All get_set* relationship accessors will will only fetch the related object(s) from the db once, after which they will just return what they've previously fetched. (The docs need to be more clear about this, I think.) This is considered a feature :) To make an object forget a previously fetched set, just set it to undef: @lists = $user->subscribed_lists(); # get list ... # modify list in the db $user->subscribed_lists(undef); # forget old list @lists = $user->subscribed_lists(); # get new list Note that this is very different from passing an empty list ([]), which says "replace the existing set of rows in the database with this new (empty, in this case) list." That's not what you want :) (As an aside, unlike the get_set* relationship methods types, the "find" method type fetches from the db every time.) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Rose::DB::Sybase implementation help
On Feb 1, 2008 3:46 PM, Ted Zlatanov <[EMAIL PROTECTED]> wrote: > I have most of the Sybase basic stuff (driver load, etc.) working for > Rose::DB, but it's pretty hacky. I'd like to make it a proper > environment, with Loader support and so on. What do I need to > implement and where? I tried to follow the PostgreSQL example and got > to listing tables, but didn't know how much of the Pg driver > functionality I need to reimplement. The DBI API defines everything RDBO needs to know except looking up unique keys (although it sort of added that too, recently). The problem is that most DBD:: drivers don't implement the entire DBI API, or don't implement all parts correctly :) In RDBO, the Pg auto-init stuff is the simplest since DBD::Pg is really good about following the DBI spec. But even then, there's some refine_dbi_*() methods in Rose::DB::(Pg|MySQL|etc.) to "massage" the output of DBI calls for certain database info. The worse case (so far :) is Informix, because DBD::Informix implements very few of the DBI introspection APIs. That's why Rose::DB::Object::Metadata::Auto::Informix is a horror show. Basically, the nicer the DBD::Sybase is, the more you can rely on the base Rose::DB::Object::Metadata::Auto and Rose::DB classes, and the less code you'll need in Rose::DB::Object::Metadata::Auto::Sybase and Rose::DB::Sybase. Some additional background: I was trying to move all db introspection stuff out of Rose::DB::Object::Metadata::Auto::* and into Rose::DB, but the problem is that many of the RDBO::...::Auto methods return RDBO::Metadata::* objects. To move those to Rose::DB, I'd need to come up with some sort of interchange format for the data (unless I wanted to make Rose::DB::Object a prerequisite for Rose::DB, which I don't :) Anyway, Rose::DB contains the table listing stuff since there's no interchange issues there (it's just a list of table names), but everything else is still in RDBO. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Loader failure on MySQL foreign key
On Feb 1, 2008 3:37 PM, Justin Ellison <[EMAIL PROTECTED]> wrote: > I was just tinkering with the loader, and might have found a bug. This should be fixed in SVN now. It was actually a method-maker bug, not a Loader bug. The Loader just happened to trigger it. Try it and let me know. I'll probably send this fix out as 0.7663 if it works for you. You should have SVN write access now, too (using your SF user/pass) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Problem using check_in with a varchar column
On Jan 31, 2008 3:44 PM, Sam Tregar <[EMAIL PROTECTED]> wrote:
> $meta->column(status => {type => 'varchar',
>default => 'normal',
> length => 32,
>check_in => ['good', 'normal',
>'in_review', 'blocked'
>]
> }
>);
>
> This produces an error:
>
> # Error: Can't locate object method "values" via package
> "Rose::DB::Object::Metadata::Column::Varchar" at
> /usr/lib/perl5/site_perl/5.8.5/Rose/DB/Object/Metadata/Column.pm line 519.
I'm assuming it only produces that error when it tries to emit the
Perl code for that class into a .pm file, right? If so, I think I
have the fix in SVN. Give it a spin and let me know if it solves your
problem.
https://rose.svn.sourceforge.net/svnroot/rose/trunk/modules/Rose-DB-Object
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Candidate for RDBO?
On Jan 30, 2008 9:23 PM, Fred Cox <[EMAIL PROTECTED]> wrote: > I've got a Postgresql DBI select: > > SELECT COUNT(*) AS voters, SUM(liked) AS liked, SUM(liked) / CAST( COUNT(*) AS > real ) AS ratio FROM review_votes WHERE reviewid=? > > that works well, but I wasn't sure whether it would be practical to try to do > this with RDBO. I know the query builder works well, but that seems to be > oriented to the WHERE clause. The Manager is not going to help you with any query that does not return a set of rows that correspond to an interconnected tree of uniquely identified rows in one or more tables. In particular, once you add an aggregate function or group by clause, the resulting rows no longer correspond to unique rows in a table and therefore cannot be represented by Rose::DB::Object-derived objects. The QueryBuilder may be of some use for building the actual SQL query, but you will then need to run it using plain old DBI. I suggest encapsulating such queries in custom Manager methods. That will hide the DBI ugliness from calling code, and you can use (or not) QueryBuilder internally depending on your needs. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] ANNOUNCE: Rose::DB::Object 0.7662 released
On Jan 29, 2008 9:25 PM, John Siracusa <[EMAIL PROTECTED]> wrote: > On Jan 29, 2008 5:28 PM, Justin Ellison <[EMAIL PROTECTED]> wrote: > > Not really a bug, but aren't you now burning extra CPU cycles on line > > 166 of RDBO::Cached? As far as I can tell, removing the line doesn't > > change the logic any. > > Whoops, copy-and-paste-o. Fixed in SVN. Maybe I'll release it as > 0.7662 tomorrow... :) Done. 0.7662 (01.30.2008) - John Siracusa <[EMAIL PROTECTED]> * Fixed copy-and-paste-o in Rose::DB::Object::Cached code. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Sharing a DBI connection with Class::DBI
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 of a try and let me know. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Sharing a DBI connection with Class::DBI
On Jan 29, 2008 9:57 PM, Sam Tregar <[EMAIL PROTECTED]> wrote: > 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. And as for DBI's, connect_cached(), you can use that (instead of the default connect()) in Rose::DB by overriding dbi_connect() in your Rose::DB subclass: http://search.cpan.org/dist/Rose-DB/lib/Rose/DB.pm#dbi_connect -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Sharing a DBI connection with Class::DBI
On Jan 29, 2008 9:52 PM, Sam Tregar <[EMAIL PROTECTED]> wrote: > 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 > web cluster when I roll out Rose::DB::Object. > > I know of one problem - Class::DBI requires its DBI handles to inherit from > DBIx::ContextualFetch while Rose wants its handle to inherit from > Rose::DB::MySQL. Anybody know how to solve this? Alternately, do you know > of other reasons why it won't work? 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. As for sharing, if you already have a DBI $dbh from elsewhere, you can simply stuff it into an appropriate Rose::DB object and use that as the "db" value in RDBO objects and calls. Just make sure that the Rose::DB object has the same driver as the DBI $dbh. Example: $dbh = ...; # get from elsewhere $db = Rose::DB->new(driver => 'mysql', dbh => $dbh); Overriding init_db() in a common base class is the usual way to do this "everywhere." There are many possible policies for init_db(). You can find a few old threads on the topic in the list archives: http://www.mail-archive.com/rose-db-object@lists.sourceforge.net/maillist.html but keep in mind the new new_or_cached() Rose::DB method that makes a lot of the caching discussion in some older threads less relevant these days. http://search.cpan.org/dist/Rose-DB/lib/Rose/DB.pm#new_or_cached Also keep in mind the funky (but useful! :) mod_perl-aware default behavior of new_or_cached()'s default cache backend: http://search.cpan.org/dist/Rose-DB/lib/Rose/DB/Cache.pm#prepare_db -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Anyone done more advanced caching with rdbo?
On Jan 29, 2008 6:52 PM, Justin Ellison <[EMAIL PROTECTED]> wrote: > Anyways, I'm in the process of writing a My::DB::CHIObject that mimics > and replaces RDBO::Cached and uses the CHI CPAN module. I'd be happy to roll this into the RDBO distribution as Rose::DB::Object::Cached::CHI. Let me know if you're interested, and if you want a commit bit so you can work on it in the RDBO SVN directly. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] ANNOUNCE: Rose::DB::Object 0.7661 released
On Jan 29, 2008 5:28 PM, Justin Ellison <[EMAIL PROTECTED]> wrote: > Not really a bug, but aren't you now burning extra CPU cycles on line > 166 of RDBO::Cached? As far as I can tell, removing the line doesn't > change the logic any. Whoops, copy-and-paste-o. Fixed in SVN. Maybe I'll release it as 0.7662 tomorrow... :) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] ANNOUNCE: Rose::DB::Object 0.7661 released
Important fix for a bug that could prevent Manager classes from loading, plus one other small change. 0.7661 (01.29.2008) - John Siracusa <[EMAIL PROTECTED]> * Fixed method clash detection in Rose::DB::Object::Manager. * Streamlined caching implementation in Rose::DB::Object::Cached. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Too Many connections
On 1/25/08 4:54 PM, maxim wrote:
> How it may work if I am using Rose::DB::Object::Loader and creating my Manager
> subclasses in the runtime ?
You can pre-create the common base class for all your classes created by the
Loader, then tell the Loader to use your base class using the base_class
parameter:
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Loader.pm#base
_class
> I ran into the same problem with looping over thousand of
> My::Manager->get_someTable() calls
Manager classes will call init_db() on their object_class if you do not pass
in a Rose::DB -derived object using the "db" parameter.
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Manager.pm#obj
ect_class
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Manager.pm#db
So either make sure your init_db() methods are set up correctly (e.g., by
defining your common base class up-front, as described above) or just pass
in a "db" parameter to every Manager call.
-John
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On
>> Behalf Of John Siracusa
>> Sent: Thursday, January 10, 2008 7:25 PM
>> To: Rose-DB-Object
>> Subject: Re: [RDBO] Too Many connections
>>
>> On 1/10/08 5:30 PM, James Masters wrote:
>>> Looking into this, I seem to simply be doing the following
>> in a "for"
>>> loop more than 100 times:
>>>
>>> my $shipobj = MGORD::Shipment->new(shipid => $shipid)->load(with
>>> =>['items', 'costs', 'problems', 'predictedcosts', 'toaddress',
>>> 'fromaddress']);
>>>
>>> So the implication is that each one of these is opening a
>> new client
>>> connection and not closing it.
>>>
>>> I know I can just increase the default connections limit
>> from 100 to
>>> say 200 to fix the problem. But is Rose really supposed to be
>>> creating all these client connections or have I written
>> something wrongly?
>>
>> When an RDBO-derived object needs a database connection, it
>> calls its db()
>> method:
>>
>>
>> http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object.pm#db
>>
>> If a db object does not yet exist, the init_db() method is
>> called to create
>> one:
>>
>>
>> http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object.
> pm#init_db
>>
>> The default implementation of init_db() returns a new
>> Rose::DB object, which in turn will create its own DBI
>> database connection.
>>
>> If you'd like one or more objects to share a single
>> Rose::DB-derived object (and therefore a single database
>> connection), a straightforward way to do it is to explicitly
>> code the sharing:
>>
>> my $db = My::DB->new; # share this among all objects created below
>>
>> for(...)
>> {
>> my $shipobj =
>> MGORD::Shipment->new(db => $db, ...)->load(...);
>> }
>>
>> If you'd rather not do this explicitly, or if you simply want
>> another default policy, then you should override the
>> init_db() method, either in your common base class or in each
>> individual RDBO-derived class, depending on the policy you want.
>>
>> For example, if you want all objects of or derived from a
>> given class to share a single database connection by default,
>> you could use the
>> new_or_cached() Rose::DB method:
>>
>> http://search.cpan.org/dist/Rose-DB/lib/Rose/DB.pm#new_or_cached
>>
>> writing an init_db() method like this:
>>
>> sub init_db { My::DB->new_or_cached }
>>
>> Remember that no matter what policy you implement in
>> init_db(), you can always explicitly create and pass a
>> Rose::DB-derived object as that value of a "db" parameter to
>> any individual object or Manager call.
>>
>> -John
>>
>>
>>
>>
>> --
>> ---
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for just about
>> anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.n
> et/marketplace
>> ___
>> Rose-db-object mailing list
>> Rose-db-object@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rose-db-object
>>
>
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Rose-db-object mailing list
> Rose-db-object@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rose-db-object
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] insert speed questions with RDBO
On Jan 23, 2008 2:07 PM, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> I found one of the problems is that you forcibly set RaiseError to 1 in
> a lot of places, in Rose::DB and Rose::DB::Object. Why override the
> connect_options?
>
> My code is working with do_transaction for now, but begin_work/commit
> should really be shown with an eval in the Rose::DB SYNOPSIS. I got the
> impression they would not die from the Rose::DB docs, so their
> exceptions were killing an outer eval, and rollback() was not called...
> I'd show you the code but it's not interesting or pretty.
The only instances I can think of off the top of my head are
local()ized changes so that I can use eval blocks internally for error
handling. For example:
sub whatever
{
...
eval
{
local $dbh->{'RaiseError'} = 1;
# do stuff
};
if($@) { ... } # handler error
else { ... } # or success
}
If there's an instance where RaiseError is altered outside and eval
block and/or not changed back before a sub returns, it's probably a
bug, so send me any cases you've found that demonstrate this.
> I ran with DBI_TRACE set high and checked that the DBD commit was only
> called as many times as I specified. So I'm using transactions to
> insert the rows, and RDBO is just not able to handle the load for my
> particular task. With COPY FROM, I can insert about 10-20 times faster
> than RDBO, so I'll have to stick with that. I'll mimic the RDBO SQL
> statements and just run them I guess...
Did you try plain DBI? I suspect even that will be 10-15 times slower
than COPY FROM. Native bulk loading is always going to win, by a lot.
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] inheriting from RBDO::Cached vs. RDBO question
On Jan 23, 2008 10:55 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote: > On Tue, 22 Jan 2008 17:17:18 -0500 "John Siracusa" <[EMAIL PROTECTED]> wrote: > JS> Anyway, when building a single super-base class, I don't think it's > JS> particularly ugly to set up your class hierarchy and then yank in a > JS> particular method (say, init_db()) from another specific class. Or > JS> like I said before, you could go the Class::C3 route and avoid all > JS> this. > > So I'd inherit from My::DB::Object first, then Rose::DB::Object::Cached? That should work as long as My::DB::Object doesn't define its own custom load(), save(), or forget(). > That might work if I understand the docs correctly. Have you done this > before, and are there any things I should beware? If it's a supported > solution to my problem, it should be in the docs because I'd imagine at > least a few more people will run into it. There's really no "supported/unsupported" distinction here. If the public methods resolve in the way you want, then you win :) > I think the Class::C3 solution is the best approach, thanks for suggesting it. Yeah, that simplifies this situation greatly (at the cost of another dependency and possibly a new set of bugs/issues :) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] insert speed questions with RDBO
On Jan 22, 2008 11:42 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote: > I'd like to try without autocommit; I tried the built-in RDBO > transactions but those didn't work well for me. begin_work was fine, > but if an error happened anywhere in the transaction, rollback() didn't > do anything and the DB rejected any further transactions. I could post > my code (I tried about 6 different ways), but I'd really like to know if > there is an example in the docs anywhere of using transactions. You can find some examples in the Rose::DB test suite: http://search.cpan.org/src/JSIRACUSA/Rose-DB-0.737/t/trx.t If you post one of your 6 ways and explain where it goes wrong, it'd make it easier to figure out where the problem is. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] inheriting from RBDO::Cached vs. RDBO question
On Jan 22, 2008 11:28 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> On Mon, 21 Jan 2008 13:24:49 -0500 "John Siracusa" <[EMAIL PROTECTED]> wrote:
> JS> When I need a mix-in, I just "make one" by manually importing methods
> JS> as needed. Writing a helper for this isn't too hard. Look around
> JS> line 560 of this file for an example:
>
> JS>
> http://search.cpan.org/src/JSIRACUSA/Rose-HTML-Objects-0.552/lib/Rose/HTML/Object.pm
>
> That's a pretty nasty hack. Really, I think this should be a standard
> mixin
Mixins are "a pretty nasty hack." That code is just automating them
:) Anyway, when building a single super-base class, I don't think
it's particularly ugly to set up your class hierarchy and then yank in
a particular method (say, init_db()) from another specific class. Or
like I said before, you could go the Class::C3 route and avoid all
this.
> instead of forcing users to derive from a different class when
> all that's changing is one small piece of the overall behavior. What
> methods are different in RDBO::Cached (I can look it up myself, but let
> me know if there are any gotchas)? I'll write the mixin code myself and
> you can put it in RDBO::Helpers or I'll make a new CPAN module for it.
If you look at the code you'll get an idea of why it's in its own
package. Yeah, it certainly could be made as a series of helpers with
some modification, but doing it as a class allows for introspection
("is this a cached object?") and better isolates any potential
ugliness or complexity of the caching implementation.
> JS> IMO, all such things are fair in super-wide-usage base classes. Do
> JS> the complicated stuff in a very few well-defined places and reap the
> JS> benefits broadly.
>
> Agreed. I'd like that place to be RDBO::Helpers, not My::DB::BaseObject :)
It'd be unlike other helpers in that it'd have its own significant
data structures off to the side (the cache itself) and it'd modify
existing methods rather than adding new ones. It sure seems like a
subclass to me. (Actually, it's perhaps more like a Perl 6 "role" but
you know... :)
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] inheriting from RBDO::Cached vs. RDBO question
On Jan 21, 2008 8:34 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote: > I have some existing RDBO classes, all inheriting from a common > BaseObject parent. If I want some of them to be selectively cached, > currently I have to create a BaseObject::Cached that inherits from > RDBO::Cached (I do this with a copy+edit, see below), and then each of > my classes can inherit from the cached variation. The issue is that any > functionality in BaseObject will not be in my cached variation unless I > do a copy+edit. I considered making BaseObject::Cached inherit from > BaseObject and RDBO::Cached but that seems like asking for trouble. I do this, and so far the world has not ended :) package MyCorp::DB::Object::Cached; use base 'Rose::DB::Object::Cached'; ... package MyProj::DB::Object; use base 'MyCorp::DB::Object'; ... package MyProj::DB::Object::Cached; use base qw(MyCorp::DB::Object::Cached MyProj::DB::Object); Obviously this doesn't allow methods in MyProj::DB::Object::Cached to override methods in MyCorp::DB::Object::Cached, but every arrangement has some tradeoff, thanks to Perl's left-most depth-first dispatch. (To get a better arrangement, you can always use Class::C3 or something...) > Is there an easier way? If a mixin could do it that would be great. I > didn't see a way in the docs. If not, maybe there's a better approach > I'm missing. When I need a mix-in, I just "make one" by manually importing methods as needed. Writing a helper for this isn't too hard. Look around line 560 of this file for an example: http://search.cpan.org/src/JSIRACUSA/Rose-HTML-Objects-0.552/lib/Rose/HTML/Object.pm IMO, all such things are fair in super-wide-usage base classes. Do the complicated stuff in a very few well-defined places and reap the benefits broadly. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Problem using primary key generator
On Jan 21, 2008 8:49 AM, Bianka Martinovic <[EMAIL PROTECTED]> wrote:
> When I look at the load()ed data, all seems fine. But later on, after
>
> $row->init( %$data );
>
> where $data contains something like
>
> {
> 'CMP_NETWORK' => {
> 'NICADDRESS' => 'a01010101011'
> },
> 'HWLASTSCANDATE' => '2008012114:33:00'
> }
>
> RDBO tries to insert() into the CMP_NETWORK table, just like you guessed. The
> question is: Why?
Is NICADDRESS the primary key of whatever class/table the CMP_NETWORK
relationship points to?
When you set a related object (either using the hashref form { ... }
or the object form, it makes no difference) RDBO will save that object
if it does not already exist. Also, using init() is the same as
making separate methods calls. So this:
$row->init
(
CMP_NETWORK =>
{
NICADDRESS => 'a01010101011',
},
HWLASTSCANDATE => '2008012114:33:00',
);
is the same as this:
$row->CMP_NETWORK({ NICADDRESS => 'a01010101011' });
$row->HWLASTSCANDATE('2008012114:33:00');
which is also the same as this:
$row->CMP_NETWORK(MyCMPNetwork->new(NICADDRESS => 'a01010101011'));
$row->HWLASTSCANDATE('2008012114:33:00');
In all cases, when it comes time to save() $row, it sees that it's had
its related CMP_NETWORK object set, and it has to decide if it needs
to save it as a new row or update an existing row. To do that, it
needs to look up the row using a primary or unique key. If none is
set, or if no existing row with that key is found, then it does an
insert.
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Problem using primary key generator
On Jan 16, 2008 11:40 AM, Bianka Martinovic <[EMAIL PROTECTED]> wrote:
> my $row = $schema->new(
> db => $dbh,
> %{
> $self->_prepare_data( $schema, { $self-
> >tableset( 'idfield' ) => $attrs{'dn'} } )
> }
> )->load;
> $row->init( %$data );
>
> (Where _prepare_data is the function to correctly map column names to
> hash keys and tableset() is a "driver function" that provides access to
> some config data for the current table. Please remember, this is a
> generic application which does not only synchronize databases.)
>
> Now, wenn storing the changes with $row->save( cascade => 1 ), the
> changes are stored as expected, _but_, a new "primary key" value is
> generated. So, for each update of this object, the value of the key
> field in the related table (CMP_NETWORK in this case) is incremented.
The primary key generator will only be called when attempting to
insert() an object that has an undef value in one or more of its
primary key columns. Recall the following from the RDBO
documentation:
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object.pm#Restriction
s
"Rose::DB::Object objects can represent rows in almost any database
table, subject to the following constraints.
* The database server must be supported by Rose::DB.
* The database table must have a primary key.
* The primary key must not allow null values in any of its columns."
If you require the ability to work with rows that have NULL values in
one or more of their primary key columns, then I suspect you ill have
some difficulty.
> Here's my primary key generator:
>
> sub default_primary_key_generator {
> my( $class, $db ) = @_;
>
> my $key = $class->meta->primary_key->column_names->[0];
>
> my %params = (
> query => [
> $key => { like => 'MAT.'.$key.'.%' },
> ],
> sort_by => $key . ' DESC',
> limit => 1,
> );
>
> my $max_id = Rose::DB::Object::Manager->get_objects(
> object_class => $class,
> %params
> );
>
> my $current = 0;
>
> if ( $max_id->[0]->{$key} =~ m|^MAT\..*\.(\d+)$| ) {
> $current = $1;
> }
> $current++;
>
> my $id = 'MAT.'.$key.'.'.sprintf( '%06d', $current );
>
> return $id;
>
> } # --- end sub default_primary_key_generator ---
You should probably pass $db to your Manager call in the function
above, otherwise it will call $class->init_db to create a new one.
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Too Many connections
On Jan 11, 2008 1:10 PM, Ted Zlatanov <[EMAIL PROTECTED]> wrote: > I think the automatic class builder should have a required option to set > the default explicitly (it didn't, last time I looked). That would > ensure the developer thought about it even in the path of least > resistance. Wat would the be the possible values for that option, an what code would each option produce? -John - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Too Many connections
On Jan 11, 2008 4:43 AM, James Masters <[EMAIL PROTECTED]> wrote: > In my naivety, it seems to me that conceptually a script would normally have > a single shared connection for all it's calls. Both from a tidiness point > of view and also because I guess it would be better performing not to keep > opening new connections (?). What is the reason for having the default > opening a new connection and not using an existing one? > > i.e. Are there any disadvantages in having a single shared connection for > multiple calls? If there were one obvious default behavior for managing db connections that everyone expected, I'd do it. Trouble is, there is no single "best" policy, and everyone's expectations differ. The existing "default unshared" behavior is intended to prevent situations where a user unfamiliar with transactions does a commit or rollback in one part of his code and is surprised to find that it committed (or undid) work done previously in another part of the code. This behavior is "obvious" if you a) understand transactions, and b) are fully aware that database connections are being shared. But you've seen, many people don't actually know what the default db connection behavior is in RDBO, so even if they understand transactions they still may be surprised by strange bugs that cause "spooky" effects in widely separated pieces of their own code. That's why I think the default unshared behavior is the "safest" in that sharing now requires some action (and therefore some thought) on the part of the developer. The required action is simple (usually a line or two of code in one place, as you've seen) and I like the fact that it forces the developer to actually formulate and stick to some sort of overall policy for connection sharing, rather than just winging it without really understanding what's going on. -John - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Too Many connections
On 1/10/08 5:30 PM, James Masters wrote:
> Looking into this, I seem to simply be doing the following in a "for" loop
> more than 100 times:
>
> my $shipobj = MGORD::Shipment->new(shipid => $shipid)->load(with =>['items',
> 'costs', 'problems', 'predictedcosts', 'toaddress', 'fromaddress']);
>
> So the implication is that each one of these is opening a new client
> connection and not closing it.
>
> I know I can just increase the default connections limit from 100 to say 200
> to fix the problem. But is Rose really supposed to be creating all these
> client connections or have I written something wrongly?
When an RDBO-derived object needs a database connection, it calls its db()
method:
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object.pm#db
If a db object does not yet exist, the init_db() method is called to create
one:
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object.pm#init_db
The default implementation of init_db() returns a new Rose::DB object, which
in turn will create its own DBI database connection.
If you'd like one or more objects to share a single Rose::DB-derived object
(and therefore a single database connection), a straightforward way to do it
is to explicitly code the sharing:
my $db = My::DB->new; # share this among all objects created below
for(...)
{
my $shipobj =
MGORD::Shipment->new(db => $db, ...)->load(...);
}
If you'd rather not do this explicitly, or if you simply want another
default policy, then you should override the init_db() method, either in
your common base class or in each individual RDBO-derived class, depending
on the policy you want.
For example, if you want all objects of or derived from a given class to
share a single database connection by default, you could use the
new_or_cached() Rose::DB method:
http://search.cpan.org/dist/Rose-DB/lib/Rose/DB.pm#new_or_cached
writing an init_db() method like this:
sub init_db { My::DB->new_or_cached }
Remember that no matter what policy you implement in init_db(), you can
always explicitly create and pass a Rose::DB-derived object as that value of
a "db" parameter to any individual object or Manager call.
-John
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Manager queries with secondary table and "or"
On 1/10/08 8:09 PM, John Siracusa wrote: > Ah, yes, you're behind the times :) You should upgrade to the latest > versions: Rose::DB 0.737 and Rose::DB::Object 0.766. Relevant to your problem > is this item from the change list for 0.765: > > * Fixed a bug that prevented relationship and foreign key names from > being resolved when used in nested query parameters. > > (http://search.cpan.org/src/JSIRACUSA/Rose-DB-0.737/Changes) Er, sorry, make that: http://search.cpan.org/src/JSIRACUSA/Rose-DB-Object-0.766/Changes -John - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Manager queries with secondary table and "or"
On 1/10/08 5:46 PM, James Masters wrote: > I'm on Rose::DB - 0.734, Rose::DB::Object - 0.764. Am I behind the times or > is this a red herring? Ah, yes, you're behind the times :) You should upgrade to the latest versions: Rose::DB 0.737 and Rose::DB::Object 0.766. Relevant to your problem is this item from the change list for 0.765: * Fixed a bug that prevented relationship and foreign key names from being resolved when used in nested query parameters. (http://search.cpan.org/src/JSIRACUSA/Rose-DB-0.737/Changes) -John - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Manager queries with secondary table and "or"
On Jan 10, 2008 1:36 PM, James Masters <[EMAIL PROTECTED]> wrote:
> I believe that I have a $spec{require_objects} = ['destaddress', ...] and
> this is working otherwise
>
> > push @query, ('destaddress.primecontact' => {like => '%smith%'});
>
> wouldn't work. [...]
>
> Anyway, your email implies that it should work so I'll have a look with the
> debug option on...
Yeah, I actually tested it locally with one of my own classes bfore I
made my earlier reply and got the same error, but then realized I'd
neglected to put the relationship name in the with_objects or
require_objects lists. When I did that, it worked fine for me.
-John
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Database Permissions when inserting (relationships).
On Jan 10, 2008 10:01 AM, Curon Davies <[EMAIL PROTECTED]> wrote:
> Hi John. Thanks for your help on this. Unfortunately that still
> doesn't quite work. If we do:
>
> $product = My::DB::Product->new(name => $^T);
> $product->add_prices(
> { price => 3.60, region => 'uk' },
> { price => 7.00, region => 'us' },
> );
>
> and then:
>
> my @prices = $product->prices;
>
> @prices is empty.
Yeah, because it's not sure that $product doesn't already exist in the
database with an existing set of prices, so the actual list of prices
is still unknown. (It's keeping the list of prices-to-add off to the
side, awaiting save().)
To make it sure that there are really no other prices, you either have
to fetch them from the db (which requires defined values for the local
columns that participate in the "prices" one-to-many relationship) or
you have to set them. (Even setting to an empty list [] would work.)
Of course, the setting option gets you right back to where you
started, so that's no good :)
> After calling new, I need to be able to access the objects created
> when passed with the 'add_prices' parameter, in a different (custom)
> method before saving the objects into the database.
Why not fiddle with the prices objects *before* passing them to add_prices()?
> Is there any way we can retain this functionality while not requiring
> DELETE database privileges?
I'm open to suggestions. Can anyone think of a good way to make this
work without breaking some existing functionality?
-John
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Manager queries with secondary table and "or"
On 1/10/08 8:19 AM, James Masters wrote:
> Have a bit of trouble with a Manager query. Trying to keep it short and
> sweet, I am searching a table "orders" which has a onetoone relationship
> called destaddress. The first 3 queries here work:
>
> push @query, ('custlastname' => {like => '%smith%'});
> push @query, ('destaddress.primecontact' => {like => '%smith%'});
> push @query, (or => ['custlastname' => {like => '%smith%'}]);
>
> but when the subtable query is put in the "OR" array viz:
>
> push @query, ('or' => ['destaddress.primecontact' => {like => '%smith%'}]);
>
> it fails with:
>
> Invalid query parameter: destaddress.primecontact at oprosemgord.pl line 991
> at C:/Perl/site/lib/Rose/DB/Object/QueryBuilder.pm line 132
Are you sure that "destaddress" appears in the with_objects or
require_objects lists?
One more thing: remember that "or" and "and" are prefix operators:
or => [ A, B, C ] -> (A OR B OR C)
and => [ A, B, C ] -> (A AND B AND C)
So including just one thing in the "or" list doesn't really do anything:
or => [ 'destaddress.primecontact' => { like => '%smith%' } ]
is just:
or => [ A ]
which becomes:
(A)
which is the same thing as not including the "or" at all and just adding
this directly to the query:
'destaddress.primecontact' => { like => '%smith%' }
-John
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Database Permissions when inserting (relationships).
On Jan 10, 2008 5:47 AM, Curon Davies <[EMAIL PROTECTED]> wrote:
> Thanks for that suggestion, something that I didn't think about. The
> add_ prefix doesn't look that nice in the constructor.
Then don't put it in the constructor call :)
$product = My::DB::Product->new(name => $^T);
$product->add_prices(...);
$product->save;
> As we would probably need to use it everywhere we create new objects for
> inserting into the database, we will probably override the constructor in
> our base class to to call the add methods instead of the
> 'get_set_on_save' method for both 'one to many' and 'many to many'
> relationships.
That seems kind of sketchy to me, but here's one way to do it. Recall
that the constructor does nothing more than call init() which then
calls the methods named by the parameters. You could get the
parameters in %args in your own custom new() method, then replace as
needed:
sub new
{
my($class, %args) = @_;
$args{'add_prices'} = delete $args{'prices'} if($args{'prices'});
return $class->SUPER::new(%args);
}
Ick (IMO). Do you have any better suggestions?
> The only problem is that our code manipulates the object before
> deciding to save the data (e.g. does our own additional validation).
> With this I can't find any way of getting to the objects that will be
> added, as $product->prices returns the empty list.
I guess that argues for doing the add_* as a separate step as shown above.
my $product = My::DB::Product->new(name => $^T);
my @prices;
foreach my $price_data ({ ... }, { ... }, ...)
{
my $price = My::DB::Price->new(%$price_data);
# Validate or manipulate $price here
...
push(@prices, $price);
}
$product->add_prices(@prices) if(@prices);
$product->save;
> I still think the get_set_on_save method should return both what is
> already in the database (unless the object isn't in the db, the primary
> key isn't set and the column type is serial), along with those that are
> going to be in the database when saved.
That'd be an unnecessary SELECT for a lot of people. If that's what
you want, I think you can ask for it by getting the list first, then
adding to it:
$product = My::DB::Product->new(...)->load;
$product->prices; # loads current prices
# or: $product = My::DB::Product->new(...)->load(with => [ 'prices' ]);
$product->add_prices(...);
# Gets the full list, current prices followed by new prices
@prices = $product->prices;
-John
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Database Permissions when inserting (relationships).
On Jan 9, 2008 2:05 PM, Curon Davies <[EMAIL PROTECTED]> wrote:
> The file works fine if the User (in this case 'rose_test') has DELETE
> permission the on 'price' table, but fails otherwise. From my
> prospective this should definitely not be the case, as the only action
> performed here is inserting into the database. Of course, I could call
> the insert method, but that defeats the point of having a common save
> method.
In your test, you are setting the "prices" one-to-many collection:
$product = My::DB::Product->new(
name => $^T,
prices =>
[
{ price => 3.60, region => 'uk' },
{ price => 7.00, region => 'us' },
]);
$product->save;
Setting the collection means replacing the existing contents (if any)
with the new contents. So the queries actually run are a DELETE and
then a series of INSERTs.
Now in this case you may "know" that this is a new record, but the
code does the same thing regardless. This is mostly done as a
safeguard or guarantee that setting a collection always really sets a
collection's entire contents.
Arguably, a feature could be added that would let the programmer
specify that these objects are not expected to already be in the db,
so don't bother with the DELETE before setting the collection. Maybe
save(insert_only => 1) or something? Maybe others have better ideas?
In the meantime, you can always express more explicitly the operations
you intend to perform. For example:
$product = My::DB::Product->new(
name => $^T,
add_prices =>
[
{ price => 3.60, region => 'uk' },
{ price => 7.00, region => 'us' },
]);
$product->save;
There should be no DELETE queries issued for that, though it may look
a bit odd to be "adding" to a collection that you expect to be empty
to start with (although that seems valid to me). A comment before
such a block could explain this, perhaps.
-John
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Proper usage of query_args?
On Jan 8, 2008 6:21 PM, Justin Ellison <[EMAIL PROTECTED]> wrote: > my $oa = $sku->object_attributes(query_args => ['attribute.atr_nm' => >$attributeName ], > )->[0]; If your relationship description was accurate, that object_attributes() method is a get_set_on_save method. By passing args to it, you're trying to set the list of object_attributes, which is not what you want. Try using the "find" method type instead: http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Metadata/Relationship/OneToMany.pm#METHOD_MAP Alternately, it's not too hard to write your own method that simply makes the appropriate Manager call (incorporating any args passed to the method, etc.) -John - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] insert speed questions with RDBO
On Jan 5, 2008 1:25 PM, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> I realize much of this question belongs to database-specific domains,
> but here goes: I want RDBO insert operations to be faster. I need to
> load thousands of records per second into a database.
The first thing to investigate is using plain DBI. If that's not fast
enough, then RDBO will never be any faster so you'll have to look
elsewhere.
The second thing to consider is bulk loading rather than INSERT
statements. You can perhaps use RDBO to produce the (usually
db-specific) bulk-load files themselves, then point the database at
the files using DBI and whatever the "load from file" syntax is for
your db.
> For example, say I have an order O100 with a single product P100 named
> "car." If I say (in pseudocode) load(O100).product("car"), and we've
> already seen that P100 is "car," the extra SELECT RDBO will normally do
> here should not happen. If we don't know P100 is "car" yet, RDBO can do
> the normal SELECT+INSERT cycle, of course. I have not seen a way to do
> this automatically in RDBO, and I think it is a common case.
I don't think I follow your example. Give me a non-psuedocode example
and I can probably tell you how to avoid any unnecessary SELECt
statements.
> I think this optimization would save me at least 10 SELECTs per record
> because the products repeat very often.
You can always make your product class inherit from
Rose::DB::Object::Cached, so each product will only be SELECTed once.
(This assumes you're actually load()ing the products, as opposed to
getting them with a JOIN via with => ... etc.)
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Cross Schema Relationships
On 1/3/08 11:14 AM, John Siracusa wrote: >> Because my schema name can change based upon domain and type (and I want >> to keep everything in My::DB), I did the following in my Inventory >> class: >> schema => My::DB->new_or_cached(type => 'custom')->schema, >> >> It works, and seems to be okay - see any problems with that? > > That should be fine, so long as the default domain is set > appropriately before that line of code is run. It occurs to me that you can also just get the schema from the registry entry itself (rather than creating and then discarding a vestigial db object). It's a bit more verbose, but arguably more clear in its intention: schema => My::DB->registry->entry(domain => My::DB->default_domain, type => 'custom')->schema, -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Cross Schema Relationships
On Jan 3, 2008 10:41 AM, Justin Ellison <[EMAIL PROTECTED]> wrote: > Thanks for the reply John - see inline: >> but then override the schema in the inventory class: >> >>> package My::Inventory; >>> >>> use base qw(Rose::DB::Object); >>> >>> __PACKAGE__->meta->setup( >>> table => 'inventory', >>> ... >>> primary_key_columns => [ qw(sku_code) ], >>> >>> schema => 'b_custom', >>> ); >> >> That should do it. > > Indeed it did. Thanks for that. I sent you a stripped down test case - > my My::DB looks more like this: > Domain TypeSchema > pts mainb_main > pts custom b_custom > prodmainprod_main > prodcustom prod_custom > > Because my schema name can change based upon domain and type (and I want > to keep everything in My::DB), I did the following in my Inventory > class: > schema => My::DB->new_or_cached(type => 'custom')->schema, > > It works, and seems to be okay - see any problems with that? That should be fine, so long as the default domain is set appropriately before that line of code is run. > I got the '$DB ||= My::DB->new;' snippet from somewhere - maybe the mailing > list? Anyways, it improved execution time on my test script by cutting it in > half. Plugging in new_or_cached into my DefaultObject class works the same, > and looks cleaner, so I'll stick with it - but is there any difference here or > is it just semantics? The new_or_cached() method, when using the default caching code and classes, does some interesting db handle preparation and cleanup when running under mod_perl. Here's the documentation chain: http://search.cpan.org/dist/Rose-DB/lib/Rose/DB.pm#new_or_cached http://search.cpan.org/dist/Rose-DB/lib/Rose/DB/Cache.pm#get_db http://search.cpan.org/dist/Rose-DB/lib/Rose/DB/Cache.pm#prepare_db You can customize these behaviors by creating your own custom db_cache_class: http://search.cpan.org/dist/Rose-DB/lib/Rose/DB.pm#db_cache_class Either way, my warning about the $DB ||= stuff in your test case code was mostly that you had it appearing in each class, rather than just once in the common base class. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Cross Schema Relationships
On 1/2/08 5:45 PM, Justin Ellison wrote:
> We have SKU's, and each row in the SKU table might or might not have a
> corresponding entry in the INVENTORY table. The gotcha here is that the
> INVENTORY table lives in a different schema than does the SKU table.
> Now, I can get at the inventory "indirectly" by manually creating a new
> Inventory object, but I can't get at it using the relationship in SKU.
> The problem is that RDBO is using the schema name from My::SKU to query
> the associated rows in INVENTORY. I'll be the first to admit that I'm
> pretty green to all this, so it's probably an error in my code, but I've
> tinkered with different things for a few hours now and can't seem to get
> it right.
If you want to do cross-schema relationships, you have to make the schema
differ per-class instead of per-data-source. (The parent object's database
connection will be used to fetch child items; I could add more flexibility
for this in the future, but it can get pretty hairy with transactions and
such...)
So, register a single data source instead of two:
> __PACKAGE__->register_db(
> domain => 'pts',
> type => 'main',
> ...);
but then override the schema in the inventory class:
> package My::Inventory;
>
> use base qw(Rose::DB::Object);
>
> __PACKAGE__->meta->setup(
> table => 'inventory',
> ...
> primary_key_columns => [ qw(sku_code) ],
>
> schema => 'b_custom',
> );
That should do it. Also, you may want to reconsider doing this in every
class:
> our $DB;
>
> sub init_db {
> $DB ||= My::DB->new;
> }
When this code appears in every class, it means that all objects of a given
class will share a single connection. That's an odd arrangement and perhaps
not what you're aiming for :)
If you want to share a Rose::DB object among all your
Rose::DB::Object-derived classes, consider using Rose::DB's new_or_cached()
method.
http://search.cpan.org/dist/Rose-DB/lib/Rose/DB.pm#new_or_cached
To share db objects only under mod_perl, this arrangement works well:
http://search.cpan.org/~jsiracusa/Rose-DB-0.737/lib/Rose/DB/Cache.pm#prepare
_db
Either way, since all your classes are now using a single data source
("pts"/"main") you should only need a single implementation of init_db() in
your common base class (rather than repeated code in each RDBO-derived
class).
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] rose-db-object
Sorry about that, guys. I mis-clicked in the admin interface when trying to discard this list spam. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] how to pluralize properly with Rose::DB::Object::Loader?
On 12/21/07 8:39 PM, Adam Prime wrote:
> sub init_convention_manager {
> my $self = shift;
>
> my $cm = $self->SUPER::init_convention_manager(@_);
>
> $cm->singular_to_plural_function(\&Lingua::EN::Inflect::Number::to_PL);
> $cm->plural_to_singular_function(\&Lingua::EN::Inflect::Number::to_S);
> return $cm;
> }
Also, FWIW, remember that the arguably better and more straightforward way
to do this is to make your own ConventionManager subclass and simply
override the singular_to_plural() and plural_to_singular() methods. (Then
set the "default" convention_manager_class() name in your Metadata subclass,
yada.)
The technique shown above (and also used as an example in the docs) is
basically just a way to avoid making a subclass if you just want to override
the singular/plural methods. But in the long run, making a proper
ConventionManager subclass is probably the best bet.
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] On load/insert/update/delete triggers?
On 12/18/07 1:38 AM, Danny Liang wrote:
> Is it possible to add triggers/coderef callbacks to
> load/insert/update/delete methods for objects and get_* methods for
> object manager classes similar to the way adding trigger to columns
> (i.e. on_set, on_save, etc.)?
There are no convenience methods for that, but you can always do it the
old-fashioned way:
sub save
{
my($self) = $_[0];
# Do my custom stuff here
return shift->SUPER::save(@_);
}
Also, be sure to read the "SUBCLASS NOTE" here:
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object.pm#load
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] matching databases with class hierarchies
On 12/21/07 3:43 PM, Ted Zlatanov wrote: > I've set up all the right things in a Rose::DB class to support this. > Now I find myself with the need for four class hierarchies to handle > slightly different things in those four environments. Instead, I'm > wondering if I can have: > > DB/auto/prod/a/Cats.pm > DB/auto/prod/b/Cats.pm > DB/auto/dev/a/Cats.pm > DB/auto/dev/b/Cats.pm > DB/Cats.pm > DB/BaseObject.pm Ick. I think the root problem is that you have four sets of tables that are "99%" identical :) You can avoid code duplication by subclassing, but it's still ugly. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] how to pluralize properly with Rose::DB::Object::Loader?
On 12/21/07 4:21 PM, Ted Zlatanov wrote: > On Fri, 21 Dec 2007 15:59:58 -0500 Hans Dieter Pearcey <[EMAIL PROTECTED]> > wrote: > HDP> On Fri, Dec 21, 2007 at 02:56:07PM -0600, Ted Zlatanov wrote: >>> I couldn't find an example in the docs of how to set up >>> Rose::DB::Object::Loader with a properly pluralizing convention manager. Your setup looks right to me, but... >>> I tried the following, but I keep getting a class called "Currencie" >>> from a table called "currencies" for example. I must be missing >>> something. ...apparently what you really need is a "properly *singularizing* convention manager." Since your tables are plural and you want singular classes, you need some code that converts English plurals to singular. But... > Unfortunately Lingua::EN::Inflect only goes from singular to plural. ...so there you have it. > Any advice or am I stuck making my own word lists? It shouldn't be too hard to make a reasonable plural-to-singular subroutine that handles all of your cases and maybe a few more :) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] good way to handle empty fields?
On Dec 15, 2007 10:43 AM, Michael Lackhoff <[EMAIL PROTECTED]> wrote: > I guess, what you are talking about is done here: > $form->init_fields_with_cgi($self->query). What is $self in that line? -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] good way to handle empty fields?
On Dec 14, 2007 2:07 AM, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> On 13.12.2007 14:03 John Siracusa wrote:
> > On Dec 13, 2007 4:24 AM, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> >> When I create a record with such a field, it is usually NULL but
> >> after some editing with the help of RHTMLO the empty field value could
> >> become '' when saved.
> >
> > I believe the latest release of Rose::HTML::Objects fixed this bug for
> > Numeric fields. That is, you should get undef for an empty Numeric
> > field instead of an empty string. Does this bug exist in other field
> > types as well?
>
> I didn't install the latest version yet but this is what I get with a
> text field:
> 1. set a field 'anrede2' to NULL with the sqlite3 command line
> 2. edit the record with RHTMLO without touching 'anrede2'
>Here is the form/field definition:
>anrede2 => {type => 'text', class => 'normfield'},
>linked to RDBO with init_with_object/object_from_form
> 3. After $obj->save I check again at the command line and it is ''
I changed the Numeric field type to convert empty string input into an
undef internal value because an empty string isn't a valid numeric
value. But in the case of a text field, an empty string is a valid
string value.
I think your problem is at a level higher: it's the thing feeding your
params() to the form. If you've decided that an empty text field
should result in an undef field value, then the piece of code you have
that converts from a query string like "a=&b=&c=123" to a hashref
suitable for feeding into $form->params() should simply take any query
parameter that has no value (i.e., a and b in the query string above)
and set it to undef in the hash.
That is, given this query string:
a=&b=&c=123
Your current hashref being fed to $form->params() looks like this:
{ a => '', b => '', c => 123 }
but you should make it look like this instead:
{ a => undef, b => undef, c => 123 }
-John
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Rose::DB array column bug
On Dec 13, 2007 11:58 AM, Derek Watson <[EMAIL PROTECTED]> wrote:
> Is there a reason why I can't set the first value of an array to NULL? I
> want to store this {NULL, 1, 2, 3} by way of an RDBO array column but I
> think the following function from Rose::DB 0.737 is preventing me from doing
> so:
>
> sub format_array
> {
> my($self) = shift;
>
> my @array = (ref $_[0]) ? @{$_[0]} : @_;
>
> return undef unless(@array && defined $array[0]);
>
> Thoughts?
Looks like a bug to me. Too bad you just missed today's release :-/
Anyway, fixed in SVN.
-John
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] ANNOUNCE: Rose::DB::Object 0.766 released
This release has some important error detection bug fixes, plus the usual collection of minor new features, including the now-officially-named "undef_overrides_default" column attribute. A new version of Rose::DB is required, which itself contains some enhancements to aid database connection sharing. Files uploaded to CPAN and SF.net. Change logs appear below. Many thanks to all that contributed to this release. -John Rose::DB::Object: 0.766 (12.13.2007) - John Siracusa <[EMAIL PROTECTED]> * Added the unique_key_by_name() metadata method. * Added the ability to do unrestricted joins in some circumstances. * Added the remember_all() class method to Rose::DB::Object::Cached. * Added the undef_overrides_default column attribute. * The key_column() method in the ForeignKey class now works correctly. (Patch by Christopher Masto) * Further synced datetime and timestamp method-maker code. * Added a test suite exclusion for DBD::SQLite 1.14, which still suffers from this bug: http://rt.cpan.org/Public/Bug/Display.html?id=21472 * Improved detection of fatal errors during class setup. * Added a "gotchas" section to the Loader documentation. * Fixed propagation of db objects in update and delete Manager methods. * Fixed a bug that caused some cached SQL to persist incorrectly after inheritance. (Patch by Daniel Koch) * Fiddled with not_found() detection. (Changes suggested by Philip Dye) * Made one-to-one relationships (attempt to) work even when uniqueness is not apparent in the metadata. * The Loader no longer chokes on SQLite columns that use the current_timestamp keyword. (Reported by George Hartzell) * Setting undef integer attributes to zero is now correctly detected as a modification. Rose::DB: 0.737 (12.13.2007) - John Siracusa <[EMAIL PROTECTED]> * Altered the behavior of connect() and disconnect() to account for the possibility that dbi_connect() may return a DBI $dbh that is already connected and has already been initialized. * Added optional (on by default) coercion of column type metadata from (big)int auto-increment to (big)serial for MySQL and SQLite. * Added support for the current_timestamp keyword to SQLite. * Added a dozen or so new MySQL connection attributes that must be inlined into the DSN rather than passed as connect() options. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] good way to handle empty fields?
On Dec 13, 2007 4:24 AM, Michael Lackhoff <[EMAIL PROTECTED]> wrote: > When I create a record with such a field, it is usually NULL but > after some editing with the help of RHTMLO the empty field value could > become '' when saved. I believe the latest release of Rose::HTML::Objects fixed this bug for Numeric fields. That is, you should get undef for an empty Numeric field instead of an empty string. Does this bug exist in other field types as well? > To make life easier I created a custom field type in RHTMLO that changes > '' to undef/NULL where necessary but I wonder if there isn't a better > way, like a RDBO parameter 'empty_sets_null' or 'false_sets_null' in a > column definition. Well, you could add an on_set trigger to all you columns to do this for you, but if it's really just an HTML field issue, it's probably better addressed there. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Remote DB connection over SSL to MySQL DB using Rose::DB
On Sep 3, 2007 9:57 PM, Kurt Hansen <[EMAIL PROTECTED]> wrote: > John Siracusa wrote: > > On 9/3/07 12:31 PM, Kurt Hansen wrote: > > > >> However, I did not try the "connect_options" method based on your > >> "inlined into the DSN" comment and reading up on the Rose::DB and DBI > >> docs. The SSL options DO need to be inlined into the DSN > >> > > > > Okay, I'll make the change in SVN when I get a chance. These are in SVN now. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] help specifying a default datetime with SQLite and RDBO::Loader
On Aug 7, 2007 4:12 PM, George Hartzell <[EMAIL PROTECTED]> wrote:
> The following little fragment of sql does what I'd like it to do,
> inserts the current timestamp into the created_date column.
>
> create table mooses (
> id integer primary key autoincrement,
> name text,
> created_date datetime not null default current_timestamp
> );
> insert into mooses(name) values ('B. Moose');
> insert into mooses(name) values ('Big Tex');
> select * from mooses;
>
> If I use Rose::DB::Object::Loader on the database created with the
> above, it complains with:
>
>insert() - Invalid default datetime: 'current_timestamp' at ... Object.pm
This is fixed in SVN. Such columns will not get a default value of "now"
-John
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Still fighting with transactions
On Aug 15, 2007 3:49 PM, Tim Bunce <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 15, 2007 at 01:06:01PM -0500, Graham Barr wrote:
> >
> > Rose::DB does not know that the $dbh it get back from connect is not a
> > newly connected handle. As a result is still goes ahead and calls init_dbh
> > which will set all the dbh attributes to the defaults.
>
> The standard approach I recommend is to check for the existence of a
> private attribute:
>
> $dbh = DBI->connect_cached(...);
> unless ($dbh->{private_foo_bar}) {
> # is new connection
> ...
> $dbh->{private_foo_bar} = ...some truee value...
> }
This is the approach I've taken in Rose::DB 0.737, soon to be released...
-John
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] ideas from Cayenne
On Dec 12, 2007 10:31 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote: > FWIW I'd use POD markup to separate custom code from auto-generated > code. It's safe, has markup properties, and can contain a comment about > its purpose. I'm more inclined to use separate .pm files, if only to keep version control diffs more transparent. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] sqlite serial column type
On Dec 12, 2007 9:48 AM, Peter Karman <[EMAIL PROTECTED]> wrote: > I don't see this in Changes in current RDBO svn. Any chance it could be > included in the next release? It's in SVN now. Thanks for the reminder. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] ideas from Cayenne
On Dec 12, 2007 8:45 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote: > I played with the Cayenne Java ORM last week. I didn't like it much > (it's very inferior to RDBO, especially in auto-generating from the > schema), but one idea that caught my eye was the 'auto' hierarchy. > Basically you get a hierarchy like this (naming simplified): > > cayenne.BaseObject > parent of >db.auto.A > parent of > db.A > > where auto.A inherits from BaseObject, and A inherits from auto.A. > Customizations go in A. All the glue code (what > Rose::DB::Object::Loader woult generate) goes in db.auto.A. Only the > db.auto.* classes are regenerated after the first run (unless you > explicitly ask to overwrite the db.* classes). You can set the base > object to something other that BaseObject. I'm not sure that kind of thing is necessary in Perl where you can alter any class at any time. In fact, it'd probably complicate matters since, in RDBO, the metadata object is class data that has to be cloned into derived classes. So you'd have this vestigial meta object lurking in the "middle" auto class for no reason (and changes to it wouldn't affect derived classes). The basic idea (safe repeated auto-generation with all customizations stored elsewhere) has been done several different ways in RDBO by others, and I've been meaning to formalize at least one way to do it. But I don't think I'd choose the "extra level of inheritance" technique. > Rose::DB::Object::Loader already supports base objects, but not this > kind of hierarchy AFAIK. It'd work (try it manually and see) but I don't think it's the best choice. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Last chance to suggest a better name for undef_sets_null
On Dec 12, 2007 8:43 AM, John Siracusa <[EMAIL PROTECTED]> wrote: > Undef is always treated as null. The distinction in this case is that > explicitly setting the column to undef overrides the default value. Okay, now I have a new favorite: undef_overrides_default That's pretty long, but it's the most descriptive so far. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Last chance to suggest a better name for undef_sets_null
On Dec 12, 2007 8:34 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote: > On Tue, 11 Dec 2007 12:10:00 -0500 "John Siracusa" <[EMAIL PROTECTED]> wrote: > JS> The undef_sets_null feature that alters the behavior of default > JS> columns values will almost certainly go out in the next release (which > JS> is coming soon). It may or may not be public (depending on if I have > JS> time to do docs and add support for it to the rest of the column > JS> types), but the code will be there. I still think the name is kind of > JS> lame, however, and I'm open to suggestions. > > (some are inverted) > > undef_is_null > undef_as_null > undef_eq_null Undef is always treated as null. The distinction in this case is that explicitly setting the column to undef overrides the default value. > explicit_null That's closer, but it feels like even less of a complete description than undef_sets_null. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Lazy Loading and Oracle?
On Dec 11, 2007 12:35 PM, Justin Ellison <[EMAIL PROTECTED]> wrote: > I was wondering if load_on_demand and Oracle was working on .765? Can you post a self-contained example script that reproduces the problem? I don't have an Oracle database readily available to test against, but lazy loading should not be db-specific anyway so if there is a bug I suspect I can reproduce it against any database. Either way, I'll need to see the code to find out. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] Last chance to suggest a better name for undef_sets_null
The undef_sets_null feature that alters the behavior of default
columns values will almost certainly go out in the next release (which
is coming soon). It may or may not be public (depending on if I have
time to do docs and add support for it to the rest of the column
types), but the code will be there. I still think the name is kind of
lame, however, and I'm open to suggestions.
A brief recap: the existing RDBO behavior for column defaults is to
return the default value when the column value is undef. So:
package Person;
...
columns =>
[
...
name => { type => 'varchar', default => 'John Doe' },
...
],
...
$p = Person->new;
print $p->name; # John Doe
$p->name('Larry Wall');
print $p->name; # Larry Wall
$p->name(undef);
print $p->name; # John Doe
The new behavior is triggered by setting the undef_sets_null column
attribute. (In this case, we'll set it directly on the column, but it
can be set class-wide or class-hierarchy-wide.)
name => { type => 'varchar', default => 'John Doe', undef_sets_null => 1 },
The behavior is now:
$p = Person->new;
print $p->name; # John Doe
$p->name('Larry Wall');
print $p->name; # Larry Wall
$p->name(undef);
print $p->name; # undef
---
So, that's the feature. Anyone have a suggestion for a different name
for undef_sets_null? Feel free to reverse the boolean nature of the
flag if it better suits your name.
-John
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] unique_keys problem
On Dec 11, 2007 10:49 AM, <[EMAIL PROTECTED]> wrote: > Will do. It might be worth noting in the loader documentation that > mysql does this, and how it affects loader, if it isn't already there > (it's entirely possible i missed it). I added a brief "gotchas" section to the Loader docs in SVN. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] unique_keys problem
On Dec 11, 2007 8:57 AM, Adam Prime <[EMAIL PROTECTED]> wrote:
> Now that i've slept i'm wondering if the underlying problem might be
> related to the way that defaults are handled in RDBO. That's one thing
> that differs between the tables used in the original tests and the table
> in the test i submitted.
Yep, that's what it is. From the docs:
http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object.pm#load
"When loading based on a unique key, unique keys are considered in the
order in which they were defined in the metadata for this class. If
the object has defined values for every column in a unique key, then
that key is used. If no such key is found, then the first key for
which the object has at least one defined value is used."
Since the "email" unique key is defined first:
unique_keys => [
[ 'email' ],
[ 'user_name' ],
],
when you run this:
$o = EatLocal::DB::User->new(user_name => 'adam');
$o->load();
RDBO first checks the "email" column and finds that it does indeed
have a defined value: its default value, '' (an empty string):
email => { type => 'varchar', default => '', length => 50, not_null => 1 },
Did you use the Loader to make these classes? MySQL tends to offer up
empty string default values for non-null character columns, and the
Loader dutifully reflects that, having no way to distinguish between
"legitimate" empty string default values that you put explicitly in
the table definition, or the "bogus" ones that MySQL auto-creates.
To avoid this problem, either eliminate the empty string default
values manually or automatically (by using the Loader's pre_init_hook
to walk the column list and remove empty string defaults) or else pass
the "use_key" parameter to load() and specify your key explicitly.
-John
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] another small suggestion for enchancement
On Nov 28, 2007 2:30 PM, maxim <[EMAIL PROTECTED]> wrote: > is it possible to overload some unary operators for > Rose::DB::Object::Iterator objects. > Like: >$iterator .= $another_iterator; >$iterator += $another_iterator; Maybe, but I certainly don't want to do it :) There's been at least one other project in this vein. Take a look at Rose::DBx::Object::InternalPager on CPAN. I don't see why something like your suggestion couldn't be implemented in a similar manner as a separate module. -John - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] suggestions for enchancement
On Nov 27, 2007 9:29 AM, Peter Karman <[EMAIL PROTECTED]> wrote: > fwiw, the DBIC folks have been discussing this very topic lately: > > http://lists.scsys.co.uk/pipermail/dbix-class/2007-November/005320.html I know. I'm on that list too :) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] suggestions for enchancement
On Nov 27, 2007, at 12:50 AM, Ron Savage wrote: > On Tue, 2007-11-27 at 00:15 -0500, John Siracusa wrote: >> I think we need a mutable object representation of SQL first, the the > > You mean like SQL::Abstract? No, definitely not like SQL::Abstract :) SQLA provides a very limited set of features: feed in Perl data structures and get out an SQL string and some bind values. I want something a lot more flexible. It's like the difference between producing HTML forms using CGI.pm and doing the same thing using Rose::HTML::Objects. I want a generic tree of mutable objects (cross-linked to the relevant bits of table metadata so they can be "smart") that only serializes to an SQL string on demand at the very end of the process. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] suggestions for enchancement
On Nov 26, 2007, at 5:29 PM, maxim wrote:
It would be nice to have abstraction layer for SQL query itself.
Yeah, no kidding :) I've got ideas for one but so far not enough time to
dedicate to it.
Something like:
my $query = Rose::DB::TableName::Manager->getSelect();
$query->someField->setCondition(eq => 'somename') if
$query->can("someField");
$query->anotherField->addCondition(lt => '1000') if
$query->can("anotherField");
$query->anotherField->addCondition( gt => '0') if
$query->can("anotherField");
my $iterator = $query->get_iterator();
Or may be you can point me to the proper technique to follow with current
implementation.
There's nothing so nice. I suppose you could simulate it by building up
Perl data structures suitable for passing to get_objects() (i.e.,
value/hashref pairs and so on) but that's not quite the same thing.
Also, is it possible to support XPath based sql queries. (like for example
'/dbname:[EMAIL PROTECTED] = "somevalue" and @field2 > "1000"]' )
It might lead to some interesting applications where direct mapping from
some XML chunk is one of thoughts.
I think we need a mutable object representation of SQL first, the the same
thing for a set of results. Then maybe after that we can think about
translating from one query syntax (e.g., XPath) to another.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] suggestions for enchancement
On Nov 26, 2007, at 5:29 PM, maxim wrote:
> It would be nice to have abstraction layer for SQL query itself.
Yeah, no kidding :) I've got ideas for one but so far not enough time
to dedicate to it.
> Something like:
>
> my $query = Rose::DB::TableName::Manager->getSelect();
> $query->someField->setCondition(eq => 'somename') if
> $query->can("someField");
> $query->anotherField->addCondition(lt => '1000') if
> $query->can("anotherField");
> $query->anotherField->addCondition( gt => '0') if
> $query->can("anotherField");
>
> my $iterator = $query->get_iterator();
>
> Or may be you can point me to the proper technique to follow with
> current
> implementation.
There's nothing so nice. I suppose you could simulate it by building
up Perl data structures suitable for passing in a get_objects() query
parameter (i.e., value/hashref pairs and so on) but that's not quite
the same thing.
> Also, is it possible to support XPath based sql queries. (like for
> example
> '/dbname:[EMAIL PROTECTED] = "somevalue" and @field2 > "1000"]' )
> It might lead to some interesting applications where direct mapping
> from
> some XML chunk is one of thoughts.
I think we need a nice mutable object representation of SQL first,
then the same thing for a generic set of result objects. Then maybe
after that we can think about translating from one query syntax to
another.
-John
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Can't test out RDBO v0.765
On 11/24/07 6:56 PM, Bob McClure wrote: > I am having problems getting RDBO v0.765 to test out. This is a > Fedora Core 6 installation with perl v5.8.8, Rose::DB v0.736, > sqlite-3.3.6-2 (from RPM), DBD::SQLite v1.14, DBI v1.52. RDBO v0.760 > tested and installed fine. DBD::SQLite 1.13 and 1.14 are buggy and are known not to work with RDBO. Unfortunately, RDBO 0.765 was released before DBD::SQLite 1.14, so it did not know to skip SQLite tests when DBD::SQLite 1.14 is installed. The upcoming version of RDBO does correctly detect and skip DBD::SQLite 1.14. In the meantime, to force RDBO to skip SQLite tests, set the RDBO_NO_SQLITE environment variable to "1" before running the tests. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Wanted: Perl programmers (Boston, MA)
On Nov 19, 2007 10:23 AM, Perrin Harkins <[EMAIL PROTECTED]> wrote: > When is the Rose web framework coming to CPAN? I'm ready for it. Not any time soon, I'm sure. What I'm using at work is more like a prototype. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] meta / setup design
On 11/16/07 5:41 PM, Jonathan Vanasco wrote: > Would you mind elaborating on how __PACKAGE__->meta and ->setup work? Maybe a week from now. I'll be away all next week. While I'm gone, check out the source :) Here's the 5 second version: The meta object is class data, one object per RDBO-derived class. The setup() method is really just the initialize() method with a guard flag to keep it from being repeatedly called by accident, plus some syntactic sugar. -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Wanted: Perl programmers (Boston, MA)
On 11/16/07 5:38 PM, Jonathan Vanasco wrote: > "This position requires does require occasionally lifting up to 20 > (twenty) pounds" > > I don't even know where to begin on that one... Apparently it's some sort of ADA requirement. (Or so says HR...) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
