On 1/19/04 4:28 AM, Matt Sergeant wrote:
> On 18 Jan 2004, at 17:14, John Siracusa wrote:
>> This topic came up before, when DateTime was just getting off the ground.
>> DateTime is a lot more mature now, and I still think it's a good idea :)
>>
>> Along those lines, all of my DBI wrappers have also had a uniform API for
>> DB-specific date parsing and formatting. My most recent DBI wrapper uses
>> DateTime as the interchange format for dates. Like the transaction flag,
>> this should be part of DBI.
>
> I've been using DateTime in production now for a year. While I think
> it's a great module for certain tasks, the biggest downfall is its
> size. It's ENORMOUS. Even compared to the DBI (last time I checked
> anyway). I'd be against mandating it, but would be happy with a
> flexible system whereby you could have an accessor mapping function, so
> you could get back DateTime objects for dates, or Time::Piece objects,
> or whatever alternative you can come up with (and apply the same logic
> to other data types).
"ENORMOUS" in terms of memory overhead? It depends on the context, I guess.
If you don't make something required, then no one can use the parse_*() and
format_*() functions in DBI unless they first explicitly register column
type handlers for each DBD. That's a pain. I'd rather see DateTime be the
default, but have it not loaded at all if something else is specified.
Example:
use DBI;
# Loads DateTime::Format::DBI by default
use DBI::ColumnTypes 'dates';
# DateTime::Format::Pg will be loaded on-demand by DateTime::Format::DBI
use DBD::Pg;
or
# Light-weight
use DBI;
# Loads the fictional Time::Piece::Format::DBI
use DBI::ColumnTypes (dates => 'Time::Piece::DBI');
# The fictional Time::Piece::::Pg will be loaded on-demand
use DBD::Pg;
There may need to be trivial wrappers around DateTime::Format::* to fit
whatever API DBI comes up with for parsing/formatting column types, but the
idea is the same.
No date parsing/formatting modules are loaded at all unless there is at
least one "registration" or use() statement of DBI::ColumnTypes (or whatever
the class is called). In the absence of a specific class for the "dates"
umbrella column type, the DateTime modules are loaded. That doesn't mean
all those DateTime modules are "required", just that people who want this
functionality will have to have *some* sort of appropriate modules loaded.
-John
