Hi,
I'm moderately new to R:D:O - so I just want to sanity check that the
following is reasonable / idiomatic.
I've got a whole mess-o-tables that (by and large)
Rose::DB::Object::Loader deals with splendidly. However, there are a
few columns where I would like to do a little client-side
Adrian == Adrian Howard [EMAIL PROTECTED] writes:
Adrian I've got a whole mess-o-tables that (by and large)
Adrian Rose::DB::Object::Loader deals with splendidly. However, there are a
Adrian few columns where I would like to do a little client-side stuff
Adrian before I update a column in
On 21 Feb 2007, at 13:51, Randal L. Schwartz wrote:
Adrian == Adrian Howard [EMAIL PROTECTED] writes:
Adrian I've got a whole mess-o-tables that (by and large)
Adrian Rose::DB::Object::Loader deals with splendidly. However,
there are a
Adrian few columns where I would like to do a little
On 2/21/07, Adrian Howard [EMAIL PROTECTED] 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 21 Feb 2007, at 14:40, John Siracusa wrote:
[snip]
That's reasonable. I've done similar things in generated and manually
created classes.
[snip]
Super :)
As I understand it triggers happen after the object is updated in
memory. I
want to shim stuff in before this (so I can preserve
On Feb 21, 2007, at 6:10 AM, Adrian Howard wrote:
Reasonable? Is there a better way (for some definition of better)?
personally, i use wrappers for all my rdb objects
my 'page objects' can only write to 'data objects'
the data objects handle loading / unloading rose objects as internal
On Wed, 21 Feb 2007 09:40:53 -0500 John Siracusa [EMAIL PROTECTED] wrote:
JS You're right that the on_set trigger happens after the column value
JS has been set. I could probably stand to add a few more trigger events
JS (e.g., before_set) but I'm wary of trigger-itis gumming up the works.
JS
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
Ask Bjørn Hansen wrote:
Note the default to foo.
MySQL, correctly, says the default is NULL:
mysql show create table bars\G
*** 1. row ***
Table: bars
Create Table: CREATE TABLE `bars` (
`id` int(10) unsigned NOT NULL,
`foo`
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 really is ''.
On Feb 21, 2007, at 11:44 AM, Ask Bjørn Hansen
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 really is
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?
It's a
On Wed, February 21, 2007 4:14 pm, Michael Reece wrote:
i am curious, if you set sql_mode=strict_trans_tables;, what
happens if you insert into bars set id=1; (with the original schema
that had an id column, of course)?
does it give the cannot be null error?
Yes. You get
mysql insert into
13 matches
Mail list logo
