Re: Re: Re: Re: Date conversion with Class::DBI

That's a good, clear explanation of what it going on.

My issue is that I have customizable tables that I'm trying to handle generically and I wanted to avoid having to treat date columns differently. Either by calling methods or writing wrappers. I want the mutator to accept D/M/Y strings, even sloppy ones. Given all this, is has_a still what I'm after? Or is changing the accessor/mutator? (Or may I should just change my requirements)

Also, this was partly an exercise in understanding Class::DBI for me. I didn't expect the inflate method to be used via the mutator.

Thanks a lot anyway,
Brad

PS.You could probably write a custom module that inherits from Time::Piece::MySQL.
Note that Time::Piece::MySQL doesn't actually inherit from Time::Piece. Time::Piece is a difficult base class.

Comment on Re: Re: Re: Re: Date conversion with Class::DBI

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Date conversion with Class::DBI by cees (Curate) on Jul 08, 2003 at 04:55 UTC
Well, I can tell by your other responses that you are aiming for the 'change the mutator' option, but since you're still open for suggestions, I'll try to extend my suggestion to include your other requirements. Read more... (4 kB) Cheers, Cees ps I have enjoyed this endevour and thank you for the question. I have learned a bit more about has_a and what can be done with it, so even if you choose not to go this route, I am happy to have learned something myself :)	[reply] [d/l] [select]
... Re: Date conversion with Class::DBI by bsb (Priest) on Jul 08, 2003 at 08:59 UTC
Another great post. It's nice to know it can be done. I may even end up doing it this way now. You are still dealing with an object, so you need to be careful when passing it to other functions if they expect a string I was thinking about tie-ing a scalar but that's one of my personal red-flags-to-insanity so I stopped.	[reply]