in reply to Date conversion with Class::DBI

I've come across this situation with Oracle. Here is how Class::DBI works in regards to has_a. 
__PACKAGE__->has_a(
    startdate => 'Date::Class',
    inflate => sub { Date::Class->new(shift) },
    deflate => 'some_method_name'
);

[download]
In the above example, you tell Class::DBI that the field
startdate should be 'modeled' by a Date::Class object.
Thus when a record is retrieved from the database
the value stored in the database is passed to the
anonymous sub, the anonymous sub is expected to
return an object reference to a Date::Class object.
When you construct an object from scratch
(you are wanting to insert a new record).
A common misconception is that you put a string
representing the date when in fact you must instead
put an object reference to Date::Class. For example:

Incorrect:

SomeTab->create({startdate => '07/08/03'});

[download]

Correct:

SomeTab->create({startdate => Date::Class->new('07/08/03')});

[download]

The deflate value if present is the name of a method of
the Date::Class object that will return a string of
the proper format for insertion into the database.
Or if Date::Class objects will stringify properly you
may leave the deflate key out all together.

We struggled with this for quite some time
only after reading through the Class::DBI code did I
come to this conclusion, as it is very poorly documented
One thing to note, you should replace Date::Class with
some real class which deals with dates.

For our purposes I used Date::EzDate, as it seemed to
easily support the most formats for parsing input
I subclassed Date::EzDate to get the default ouput
format that we needed to work.

I hope this helps if you need further assistance please
contact me, mgrubb-web-perlmonks at fifthvision dot net

Replies are listed 'Best First'.
Re: Re: Date conversion with Class::DBI
by cees (Curate) on Jul 09, 2003 at 22:19 UTC

    That is a good explaination of what is going on with with the has_a relationships. I agree with you that the documentation for Class::DBI in regards to this is not that great, and it took me a while to figure things out as well.

    I have a couple of small additions to make to clarify or simplify your example.

    __PACKAGE__->has_a(
    startdate => 'Date::Class',
    inflate => sub { Date::Class->new(shift) },
    deflate => 'some_method_name'
);

    [download]

    That code can be reduced to:

    __PACKAGE__->has_a(
    startdate => 'Date::Class',
    inflate => 'new',
    deflate => 'some_method_name'
);

    [download]

    Since by default Class::DBI will call the inflate method as a class method and pass it the value as the first arguement. It can even be reduced to:

    __PACKAGE__->has_a(
    startdate => 'Date::Class',
    deflate => 'some_method_name'
);

    [download]

    Since 'new' is the default method used for inflation.

    Similarly, for the deflate method, stringification is used by default. So if you don't provide a 'deflate' method, then Class::DBI will assume that your object overrides "" and will stringify it to deflate it.

    Also, a small correction, you mention that the following is incorrect:

    SomeTab->create({startdate => '07/08/03'});

    [download]

    That will actually work, since Class::DBI is smart enough to call the 'inflate' method when you pass it a string. I will agree that it is better in most cases to pass an object, but a string will work just as well. The only caveat is that the string you pass must be consistent with what 'deflate' actually generates.

    So in other words, you can pass it a 'deflated' string or an 'inflated' object and Class::DBI will do the right thing.

    There seems to be enough information in this thread to get a good start on a Tutorial on relationships in Class::DBI...

    Cheers,

    Cees

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom