> "John" == John Siracusa <[EMAIL PROTECTED]> writes:
John> On 1/17/07 8:29 PM, Randal L. Schwartz wrote:
John> % svn co https://svn.sourceforget.net/svnroot/rose/trunk/modules/Rose-DB
>>
>> Hmm. This just hangs.
John> My fingers have minds of their own. s/forget/forge/
source forget. he
On 1/17/07 8:29 PM, Randal L. Schwartz wrote:
> John> % svn co https://svn.sourceforget.net/svnroot/rose/trunk/modules/Rose-DB
>
> Hmm. This just hangs.
My fingers have minds of their own. s/forget/forge/
-John
-
Take
> "John" == John Siracusa <[EMAIL PROTECTED]> writes:
John> What database(s) are you testing against?
Just sqlite.
John> Can you try checking out the
John> SVN version and running individual tests in-place?
John> % svn co https://svn.sourceforget.net/svnroot/rose/trunk/modules/Rose-DB
Hmm
On 1/17/07 6:49 PM, Randal L. Schwartz wrote:
> Failed Test Stat Wstat Total Fail List of Failed
> -
> t/db-object-changes-only-1.t 255 65280 4834 482-483
> t/db-object.t 255 65280 543
On 1/17/07 7:12 PM, Cory Bennett wrote:
> Is there a way to reset the data cached from relationship queries?
Just set the collection to undef:
$p->prices(undef);
@prices = $p->prices; # re-fetched from the database here
-John
---
On 1/17/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
> On Jan 17, 2007, at 12:56 PM, John Siracusa wrote:
>> But now that I look further, it appears that it's the "describe
>> mytable" output that's incorrect (or at least misleading). When I
>> insert a row without specifying a value for that V
Is there a way to reset the data cached from relationship queries?
If I have something like:
my $p = Product->new(name => "Kite")->load();
for my $price ( $p->prices() ) {
print "price: ", $price->price, "[", $price->region, "]\n";
}
Which prints:
price: 7.79[DE]
price: 1.11[JP]
The in the s
On Wed, 2007-01-17 at 17:33 -0500, John Siracusa wrote:
> I was ignoring strict mode for the purposes of this exploration. Even
> in "crazy old MySQL mode" I think the "describe table" output should
> more closely match what's returned by DBD::mysql in COLUMN_DEF.
I agree, that sounds like a bug
Failed Test Stat Wstat Total Fail List of Failed
---
t/db-object-changes-only-1.t 255 65280 4834 482-483
t/db-object.t 255 65280 5434 542-543
5996 subtests skipped.
Failed 2
>What versions of RDBO and Pg are you using?
>The Loader should work, and does work here when I try it with Pg 8.2.0
>and the latest RDBO. I created the tables in my database by copying
>and pasting the definitions you posted earlier. Here's the Perl code
>I used to test it:
hmm..I did the same
>mysql behaves DRASTICALLY different depending on that flag. it might
>actually do what you expect it to when turned on.
>// Jonathan Vanasco
"It might actually do what you expect"... hehe...well said!
-
Take Surveys.
On Jan 17, 2007, at 2:08 AM, Neal Clark wrote:
> the stuff table is huge. the actual requirements are "infinite rows
> spanning an infinite amount of disk space," but i'm working with my
then stuff like this:
> accounts INTEGER[]
> id SERIAL PRIMARY KEY
should be (in postgres):
>
On Jan 17, 2007, at 12:56 PM, John Siracusa wrote:
> But now that I look further, it appears that it's the "describe
> mytable" output that's incorrect (or at least misleading). When I
> insert a row without specifying a value for that VARCHAR(10) NOT NULL
> column, it ends up with an empty strin
On 1/17/07, Cory Bennett <[EMAIL PROTECTED]> wrote:
>> This is arguably a bug in DBD::mysql, but as far as RDBO is concerned,
>
> For what it is worth, I dont think it is strictly DBD::mysql's fault, it is
> Mysql itself.
>
> http://dev.mysql.com/doc/refman/5.0/en/data-type-defaults.html
>
> It mig
On Wed, 2007-01-17 at 10:01 -0500, John Siracusa wrote:
> I'm forwarding this private email thread to the list with the
> permission of the (now anonymized) sender because it's about an
> unexpected situation that many RDBO users may face. Yes, it revolves
> around yet another fun feature of MySQL
> This is arguably a bug in DBD::mysql, but as far as RDBO is concerned,
For what it is worth, I dont think it is strictly DBD::mysql's fault, it is
Mysql itself.
http://dev.mysql.com/doc/refman/5.0/en/data-type-defaults.html
It might be fixed with mysql 5.0.2, but I do not have that version
On 1/17/07, Praveen Ray <[EMAIL PROTECTED]> wrote:
> Thanks. Are you saying, Loader will detect these foreign key based
> relationships and generate methods accordingly - something that
> auto_initialize is not able to do (unless we load the modules in proper
> order)?
It's not about order, it's a
On 1/17/07, Neal Clark <[EMAIL PROTECTED]> wrote:
> given then accounts INTEGER[] way of doing this, will rose db do this:
>
> @accounts = $stuff->accounts;
>
> and convert the ARRAY[id,id,id] into a perl array?
Yes, so long as you set up the column metadata correctly, either by
auto-initializing
I'm forwarding this private email thread to the list with the
permission of the (now anonymized) sender because it's about an
unexpected situation that many RDBO users may face. Yes, it revolves
around yet another fun feature of MySQL/DBD::mysql. How did you
guess? :)
Anyway, here it is, for pos
19 matches
Mail list logo
