I'm very interested in the new DBD::AnyData as I use it to work with CSV
files in conjunction with DBI::PurePerl. Does the new version that's
in the works have any speed/resource/architecture improvements? I
thought it was mentioned previously that it would be revised based on
lessons learned while working on DBI::PurePerl. Or am I thinking of
the pending (if there is a pending) SQL::Statement revisions? Just
curious - thanks for a great module.
I'd be glad to beta the new version and/or do some hi res timer
comparisons if needed. Please let me know if I can help at all.
Nick Hendler
[EMAIL PROTECTED]
_________________________________________
From: Jeff Zucker <[EMAIL PROTECTED]>
Date: Thursday, October 3, 2002
Time: 10:41:36 PM
Subject: AnyData Conversion (Was Re: Uploaded to CPAN: DBIx::Dump)
Sterin, Ilya wrote:
> That would be fine. I was thinking in terms of supporting data formats that
> can't be queried,
Yes, there are already some like that, for example one can query Mp3
file embedded text tags, but not create or modify them.
> AnyData.pm, I haven't looked at the source,
Don't :-). Look at the development version which is migrating to a
dispatch_method similar to DBI::PurePerl (which is part of why it's
taking me so long for the next release).
> I'm not sure if Jeff wants to
> add these misceleneous data structures.
The more the merrier. Users have developed task-specific AnyData
parsers for things like genomes and sun-flare reports. See the list
below for a half dozen other general formats developed by other authors.
> I just added an event driven interface to DBIx::Dump, which allows to define
> event handlers and due on the fly transformations/formatting before
> outputting. Not sure about the AnyData interface and if it will allow for
> such additions without much reprogramming.
On the contrary, there is support already for both post-read and
pre-write event handlers in the development version of the module as
well as support for on-the-fly user-defined parsers.
> Jeff???
Yes, Ilya, let's collaborate!!!
Here's what adConvert will look like in the next release (90% of it is
available in the current version):
adConvert({
data_source => $filename
| *file_handle
| $http_url
| $ftp_url
| [$string]
| [<DATA>]
| $array_of_arrays
| $array_of_hashes
| $dbi_database_handle
| $dbi_query_statement_handle,
data_target => $filename
| *file_handle
| $dbi_insert_statement_handle,
| undef (returns a string, AoA,or AoH
depending on the specified target
format)
source_format => CSV
| Tab
| Pipe
| Space
| Ini
| XML
| DBI
| Fixed (with Doug Wilson)
| SNMP (by Wes Hardaker)
| Excel (by Kawai, Takinori)
| Syslog (by Tod Harter)
| MLDBM (in progress, with Brian Hann)
| HTMLtable
| Storable
| Passwd
| Weblog
| Mbox (anyone want to collaborate or take
on this one?)
| AoA
| AoH
| FileSys
| Mp3
| Usr (user-defined)
| $your_format_here (please submit format parsers
the next release will have an
actual API for them)
target_format => (same as source formats except for Mp3)
flags => (various flags, most with defaults
to determine method of finding colnames;
set a file_locking mechanism if needed,
set delimiter, separator, quote and escape chars;
define pre-write and post-read handler routines)
});
