On Sep 7, 2007, at 5:23, John Siracusa wrote:
> But what about all the existing code that expects undef to trigger
> the use
> of the default value?
They should set the
"CRAZY_DEPRECATED_BACKWARDS_COMPATIBLE_MODE_ENABLED" variable. ;-)
Whatever the fix, I agree with Graham that it should b
On Sep 6, 2007, at 7:16 PM, John Siracusa wrote:
> Or I suppose you could do the reverse, requiring a "special" value to
> trigger the use of a default and leaving undef as the null stand-in.
That'd by far be my preference. In the application code undef and
NULL maps so beautifully. Also it
On Sep 6, 2007, at 19:01, Ask Bjørn Hansen wrote:
> We have some columns that are NULL but with a specified default value
> (for example "0").
>
> deleted => { type => 'integer', default => '0' },
Graham pointed out (in IM)
Hi everyone,
We have some columns that are NULL but with a specified default value
(for example "0").
deleted => { type => 'integer', default => '0' },
Sometimes we need to set it to undef/NULL (a valid value), but RDBO
unhelpfully resets that to the default value ("0").
On Jun 15, 2007, at 22:32, Peter Karman wrote:
We have a similar thing too,
https://svn.develooper.com/combust/trunk/bin/scaffold_schema
Example output in
https://svn.develooper.com/projects/ntppool/trunk/lib/NP/Model.pm
One of the clever things we have is that the model loads e
On May 18, 2007, at 9:00 AM, John Siracusa wrote:
> Since those sections are clearly labeled and there are links to all
> the major sections (in the HTML version of the POD, that is), I don't
> think it's too onerous for those people that want to skip them to do
> so.
Since nobody else agreed wi
On Apr 27, 2007, at 7:25, John Siracusa wrote:
> Sorry for any delays in responding to RDBO issues or email. We just
> had a baby (our second) and things will likely be a bit hectic here
> for a while... :)
Congratulations! :-D
- ask
--
http://develooper.com/ - http://askask.com/
---
On Apr 23, 2007, at 9:19, Ovid wrote:
[mysql truncating data values]
>> Upgrade to 5.x and turn on 'STRICT MODE' or SQL STANDARD mode - one
>> or both of those settings will fix that.
>
> I wish :(
No, it really does.
- ask
mysql> create table t ( foo enum("bar", "baz") ) engine=InnoDB;
Quer
On Apr 21, 2007, at 8:19 PM, Jonathan Vanasco wrote:
>> I took a quick pass at a strip() helper it and checked it into SVN.
>> Try it and let me know what you think. (You'll also need to check
>> out
>> the latest Rose::Object to get the new MixIn class.)
>>
>
> Great! Thanks.
Thanks from me
On Apr 19, 2007, at 9:37 PM, Bill Moseley wrote:
> It's the Manager that seems to be closing the connection.
> Perhaps I'm using it incorrectly?
I don't really know what I'm talking about here, but in our Rose::DB
class[1] we have this,
sub DESTROY { } # Avoid disconnect being called
(the de
On Feb 21, 2007, at 3:10, Adrian Howard wrote:
> Rose::DB::Object::Loader->new(
> db => MyApp::DB->new,
> class_prefix => 'MyApp'
> )->make_classes(
> pre_init_hook => sub {
> my $meta = shift;
> $meta->column( 'some_column' )->alias( '_some_column' )
>
On Feb 21, 2007, at 1:23 PM, Danial Pearce wrote:
>> You got the SQL_MODE setting "wrong". :-)
>>
>> set sql_mode=strict_trans_tables;
>
> Does that SQL_MODE apply to the create table, and stay there? Or does
> it apply to the insert and maybe you didnt need to have it set when
> you created?
I
On Feb 21, 2007, at 12:35, Michael Reece wrote:
>> MySQL, correctly, says the default is NULL:
>
> i was say erroneously, not correctly.
>
> if you try this:
>
>insert into bars set id=1 ;
>select * from bars ;
>
> you will see that the foo column is '', not NULL, suggesting the
> default
On Feb 21, 2007, at 12:01, John Siracusa wrote:
> On 2/21/07, Ask Bjørn Hansen <[EMAIL PROTECTED]> wrote:
>> MySQL, correctly, says the default is NULL:
>
> Try using DBI's column_info() method and see what COLUMN_DEF is set to
> for that column.
Grrh, it's
On Feb 21, 2007, at 10:00, John Siracusa wrote:
> I'm going to release 0.761 shortly. If you have any outstanding bugs
> not fixed in SVN or any other small suggestions, speak now...
Maybe this is something, once again, that I am doing wrong - but I
don't understand this:
mysql 5.0.27 and DB
Hi everyone,
I needed to run a method after every save (I add stuff to a log table
and want the code to automatically update an RRD table too).
After unsuccessfully fiddling with column level triggers for a bit, I
realized I could just override save:
sub save {
my $self = shift;
my
On Feb 16, 2007, at 10:11, John Siracusa wrote:
> Opinions?
My initial thought was "messy", but I keep typing it that way
expecting it to work so I agree with Ted, DWIM.
- ask
--
http://develooper.com/ - http://askask.com/
-
On Feb 12, 2007, at 12:20 PM, John Siracusa wrote:
> $o->load(key => '...');
This will solve the problem for me, but it really doesn't seem quite
right. Having to do ->new->load is already odd too.
I guess what I really want is to be able to do
$object_class->load(key1 => $value, ke
Hi,
If I instead of
$p->add_prices
({ price => 7.89, region => 'DE' },
{ price => 1.11, region => 'JP' });
$p->save;
do
$p->add_prices({ price => 7.89, region => 'DE' });,
$p->add_prices({ price => 1.11, region => 'JP' });,
$p->save;
then it appear
With RDBO 0.760 I have a class setup like the following,
__PACKAGE__->meta->setup(
table => 'users',
columns => [
id => { type => 'integer', not_null => 1 },
email => { type => 'varchar', default => '', length =>
255, not_null => 1 },
name =
Hi John (and everyone else),
I suggest changing the looks_like_map_table to not match "foo_bars",
but only *_map and "foos_bars". I realize we can just override it in
our convention manager, but it's a goofy default, I think. Either I
don't understand entirely how the looks_like_map_metho
On Feb 8, 2007, at 5:22 PM, Michael Reece wrote:
> and get the right datetime value, but is there an easy way to
> influence the timezone on all DateTime objects created by
> Rose::DB::Object?
I had the same problem yesterday (sorta).While on the subject I'd
(generally) highly recommend u
On Feb 6, 2007, at 11:22 AM, John Siracusa wrote:
> I'm not a big fan of the *_now method types, however, which is why
> they're not the defaults. OTOH, a delete_on_save method might seem
> strange when doing something like this:
I don't think so.
I was working on converting a small CDBI app (
On Jan 30, 2007, at 12:55, John Siracusa wrote:
I like it!
We have all sorts of utility methods in our model classes to fetch
child objects where just calling ->children wasn't exact enough.
On a vaguely related note, in our manager class we have the following
three methods. In particular
On Jan 15, 2007, at 3:45 PM, Robert James Kaes wrote:
[RDBO not playing nice with module reloading]
> I was rather afraid of that. :( I had hoped that someone smarter
> than I
> had come up with a work-around.
In our (still secret) RDBO-using project we have all the "RDBO-stuff"
in a Foo::M
On Jan 5, 2007, at 6:08 PM, Jonathan Vanasco wrote:
> for small stuff, not a problem. for large stuff, i think it is --
> which is why i'm a little shocked at the original poster. i'd be
> scared shitless to be dealing with an 18M row mysql db myself.
5+ years ago I worked at a place with many
On Dec 5, 2006, at 9:00, George Hartzell wrote:
> On the other hand the hoops that they jump through to try to
> automagically generate queries and hide the relational database
> mystifies me, I find that I end up double checking the sql that they
> generate to make sure that I haven't shot mysel
On Nov 15, 2006, at 19:42, Jonathan wrote:
> SET and ENUM in mysql are super dangerous.
> They promote really bad design patterns and lock people into MySQL
> specific schema that is a "Complete Fucking Nightmare" to port to
> another DB system. If people did a standard normalized sc
On Nov 15, 2006, at 19:12, John Siracusa wrote:
[...]
> Ah ha! Hm, seems like an enum crossed with an array. Anyway, next
> question: what about values with commas in them?
"Officially not supported".
> Blah, I just tried it. In typical MySQL fashion, it silently does
> the wrong thing.
On Nov 15, 2006, at 18:35, John Siracusa wrote:
> Does MySQL actually have native SET support?
Yes,
http://dev.mysql.com/doc/refman/5.0/en/set.html
http://dev.mysql.com/tech-resources/articles/mysql-set-datatype.html
- ask
--
http://www.askbjoernhansen.com/
It'd be really nice if the tests could be split into smaller chunks.
They are pretty intimidating to us regular people...
Anyway, below is a small addition (without tests) to Rose::DB::MySQL
to add support for SET columns.
The paranoid "is it defined" tests were from the Informix version.
Hi,
We have a script that generates our classes for us, using the Loader
and a bit of custom code to tweak the generated class to our needs.
It goes something like this:
my $loader = Rose::DB::Object::Loader->new(...);
for my $class ($loader->make_classes) {
my $meta = $class->meta;
On Oct 20, 2006, at 5:39 AM, John Siracusa wrote:
[...]
> If you know the class name already, just do this:
>
> $record = $class->new(primarykeyfieldname => $pk)->load;
We (well, Graham) made the following manager class that gives us
"fetch" and "fetch_or_create" methods to shorten the ->n
On Oct 15, 2006, at 8:15, John Siracusa wrote:
> Nah, because the only time the option would appear is when you want
> to set
> it to true:
>
> allow_empty_lists => 1, # alter default behavior
Oh, you are going to make what I suggested the default. Yay. Even
better. :-)
I thought all
On Oct 14, 2006, at 7:04 PM, John Siracusa wrote:
> Hm, I was thinking more along the lines of allow_empty_lists or
> something.
I like that. (Except if allowing it is the default, then "allow_*"
feels a little backwards).
- ask
--
http://askask.com/ - http://develooper.com/
-
On Oct 13, 2006, at 16:11, John Siracusa wrote:
> On 10/13/06 7:03 PM, Ask Bjørn Hansen wrote:
>> I keep making variations of this mistake,
>>
>> Model->delete_stuff
>> (where => [ foo_id => $l->id,
>> bar_id => [ keys
Hi,
I keep making variations of this mistake,
Model->delete_stuff
(where => [ foo_id => $l->id,
bar_id => [ keys %delete_bars ],
],
db=> $db);
... with an empty %delete_bars hash.
I could use an option so it instead of deleting everything in
Hi,
With CDBI I'd often use the "trigger" system to update/maintain
"created_on" and "last_updated" fields.
With RDBO we've so far just used "TIMESTAMP" columns, but now we have
a table where we need to keep track of both when the entry was
created and when it was last updated. MySQL can'
On Sep 16, 2006, at 15:27, James Masters wrote:
Vaguely related:
On $new_project we have a "scaffold_generator" that runs the loader
and generates a Perl module (with a bunch of packages) for each of
our databases. In the generator we hardcode a few tweaks (say used
the Cached class for t
On Jul 21, 2006, at 15:21, John Siracusa wrote:
>> Also, it would be very nice if columns that don't match could
>> cause a fatal
>> error instead of being silently dropped. I will see if I can make
>> a patch for
>> that if you agree.
>
> IIRC, the existing "silent" behavior is actually use
On Jul 10, 2006, at 11:05 AM, John Siracusa wrote:
> I have similar questions for as_json(). How should this work?
Like you described (IMO).
The more complicated schemes have their place, but for 80% (98%?) of
the applications a simple hash would be much easier to deal with.
- ask
--
h
On Jun 9, 2006, at 10:16 AM, John Siracusa wrote:
> So, the question for Ask (who started the earlier thread) is, does
> this look like it can do everything you need for the GeomFromText(...)
> column type you talked about earlier?
Yup, it looks promising. I will play with it over the next few
Hi,
I'm playing with having RDBO run some of geourl.org (it is using
Class::DBI now). Some of the columns are "point" columns with a
spatial index.
When I insert or update those columns I need RDBO to wrap the data I
provide in GeomFromText() ("insert into t (name, geo) values (?,
GeomF
43 matches
Mail list logo