Re: DBD::XML
On 09/04/2016 03:41 PM, Tim Bunce wrote: On Sun, Sep 04, 2016 at 08:33:21AM -0400, Nigel Horne wrote: On 4/9/16 05:56, Tim Bunce wrote: So here's an interesting one. Any thoughts on this? I assumed it all got pulled in magically, but I guess I'm missing something. But what? http://www.cpantesters.org/cpan/report/f9cbd816-7052-11e6-ab41-c893a58a4b8c I've not listed DBI as a prerequisite, nor DBI::DBD::SqlEngine (which is the first thing the module loads) so that test might have been running with a funky older version. Thanks, Tim. The problem is that seems to be the case with a lot of smokers, not just a few, so I think it's something in need of more attention. I've added SQL::Statement to the pre-reqs since I saw that in some other code (I forget which now), I'll see if that helps. Why not also add DBI::DBD::SqlEngine (0.06, I think) as a pre-req? Seems appropriate since that's what the module 'use's. Great minds think alike, as it were, since I've done that. Now it builds OK on Travis which was patchy beforehand, so I am hoping for the best. Tim. -Nigel
Re: DBD::XML
On Sun, Sep 04, 2016 at 08:33:21AM -0400, Nigel Horne wrote: > > On 4/9/16 05:56, Tim Bunce wrote: > > > So here's an interesting one. Any thoughts on this? I assumed it all got > > > pulled in magically, but I guess I'm missing something. But what? > > > > > > http://www.cpantesters.org/cpan/report/f9cbd816-7052-11e6-ab41-c893a58a4b8c > > I've not listed DBI as a prerequisite, nor DBI::DBD::SqlEngine (which is > > the first thing the module loads) so that test might have been running > > with a funky older version. > Thanks, Tim. The problem is that seems to be the case with a lot of > smokers, not just a few, so I think it's something in need of more > attention. I've added SQL::Statement to the pre-reqs since I saw that in > some other code (I forget which now), I'll see if that helps. Why not also add DBI::DBD::SqlEngine (0.06, I think) as a pre-req? Seems appropriate since that's what the module 'use's. Tim.
Re: DBD::XML
On 4/9/16 05:56, Tim Bunce wrote: So here's an interesting one. Any thoughts on this? I assumed it all got pulled in magically, but I guess I'm missing something. But what? http://www.cpantesters.org/cpan/report/f9cbd816-7052-11e6-ab41-c893a58a4b8c I've not listed DBI as a prerequisite, nor DBI::DBD::SqlEngine (which is the first thing the module loads) so that test might have been running with a funky older version. Thanks, Tim. The problem is that seems to be the case with a lot of smokers, not just a few, so I think it's something in need of more attention. I've added SQL::Statement to the pre-reqs since I saw that in some other code (I forget which now), I'll see if that helps. Tim. -Nigel
Re: DBD::XML
On Thu, Sep 01, 2016 at 01:53:52PM -0400, Nigel Horne wrote: > So here's an interesting one. Any thoughts on this? I assumed it all got > pulled in magically, but I guess I'm missing something. But what? > > http://www.cpantesters.org/cpan/report/f9cbd816-7052-11e6-ab41-c893a58a4b8c I've not listed DBI as a prerequisite, nor DBI::DBD::SqlEngine (which is the first thing the module loads) so that test might have been running with a funky older version. Tim.
Re: DBD::XML
So here's an interesting one. Any thoughts on this? I assumed it all got pulled in magically, but I guess I'm missing something. But what? http://www.cpantesters.org/cpan/report/f9cbd816-7052-11e6-ab41-c893a58a4b8c -Nigel -- Nigel Horne Conductor: Rockville Brass Band, Washington Metropolitan GSO @nigelhorne | fb/nigel.horne | bandsman.co.uk | concert-bands.co.uk | www.nigelhorne.com Unless it's for my eyes only, please use "reply all" smime.p7s Description: S/MIME Cryptographic Signature
Re: DBD::XML
Hi Ron, On 01/09/16 02:02, Nigel Horne wrote: Uploaded to https://metacpan.org/release/NHORNE/DBD-XMLSimple-0.01 Now to see what the cpantesters come up with. The 2nd line of the Synopsis looks like it's meant to be N separate lines. I saw that had formatted incorrectly on CPAN. It's on my list. -Nigel -- Nigel Horne Conductor: Rockville Brass Band, Washington Metropolitan GSO @nigelhorne | fb/nigel.horne | bandsman.co.uk | concert-bands.co.uk | www.nigelhorne.com Unless it's for my eyes only, please use "reply all" smime.p7s Description: S/MIME Cryptographic Signature
Re: DBD::XML
Hi Nigel On 01/09/16 02:02, Nigel Horne wrote: Uploaded to https://metacpan.org/release/NHORNE/DBD-XMLSimple-0.01 Now to see what the cpantesters come up with. The 2nd line of the Synopsis looks like it's meant to be N separate lines. -- Ron Savage - savage.net.au
Re: DBD::XML
Uploaded to https://metacpan.org/release/NHORNE/DBD-XMLSimple-0.01 Now to see what the cpantesters come up with. -Nigel -- Nigel Horne Conductor: Rockville Brass Band, Washington Metropolitan GSO @nigelhorne | fb/nigel.horne | bandsman.co.uk | concert-bands.co.uk | www.nigelhorne.com Unless it's for my eyes only, please use "reply all" smime.p7s Description: S/MIME Cryptographic Signature
Re: DBD::XML
On 8/21/16 4:34 PM, Tim Bunce wrote: On Sun, Aug 21, 2016 at 02:29:49PM -0400, Nigel Horne wrote: Anyway, back to the topic of naming... I'd suggest something like DBD::XMLSimpleTable which would have a corresponding prefix of 'xmlst_'. Not so sure about Table - how about DBD::XMLSimple? Yeap. That seems fine. So DBD::XMLSimple and a prefix of xmls_. Yes, that works for me. Thanks. Tim. -Nigel smime.p7s Description: S/MIME Cryptographic Signature
Re: DBD::XML
Hi Ron,
On 19/8/16 20:24, Ron Savage wrote:
Hi Nigel
On 20/08/16 01:51, Tim Bunce wrote:
On Fri, Aug 19, 2016 at 10:09:45AM -0400, Nigel Horne wrote:
On 8/19/16 9:56 AM, Tim Bunce wrote:
On Fri, Aug 19, 2016 at 09:30:32AM -0400, Nigel Horne wrote:
[snip]
But I wonder about the name. "DBD::XML" seems to be a bold name,
implying that it's _the_ DBI interface for data stored in XML files.
Of course the same kind of issue applies to many other drivers,
so it's not a major concern, but does seem worth dicussing.
I'm more than happy to entertain other names if you have any
suggestions.
As a rule, we have DBI (there's just one) and anything it uses
(DBI::*), and then we have DBIx::* for all our additions in thefield.
That is, we all agree to explicitly avoid using DBI::*. Even drivers
loaded by DBI are called DBD::Pg, DBD::mysql, DBD::SQLite, etc.
This usage of $ABCx or $AbcX is a wide-spread convention. E.g.
Marpa::* is exclusively used by Jeffrey Kegler, and all ours are
MarpaX::*. But there are many, many modules called ${Something}x::* as
add-ons to $Something.
And yes, for DBI and other it's 'x', elsewhere it's often 'X'.
For clarification, are you saying that my driver should be called
DBDx::XML? The reason I ask is that all the DBDx::* modules I could
find seem to be extensions to DBI or things that use DBI, rather than
DBI drivers or backends.
Also would that confuse with the existing DBIx::XML code? That does
something entirely different.
-Nigel
Re: DBD::XML
On Sun, Aug 21, 2016 at 02:29:49PM -0400, Nigel Horne wrote: > > > Anyway, back to the topic of naming... I'd suggest something like > > DBD::XMLSimpleTable which would have a corresponding prefix of 'xmlst_'. > > Not so sure about Table - how about DBD::XMLSimple? Yeap. That seems fine. So DBD::XMLSimple and a prefix of xmls_. Tim.
Re: DBD::XML
Anyway, back to the topic of naming... I'd suggest something like DBD::XMLSimpleTable which would have a corresponding prefix of 'xmlst_'. Not so sure about Table - how about DBD::XMLSimple? Sound ok? Tim. -Nigel
Re: Fwd: Re: DBD::XML
Hi Nigel
This usage of $ABCx or $AbcX is a wide-spread convention. E.g.
Marpa::* is exclusively used by Jeffrey Kegler, and all ours are
MarpaX::*. But there are many, many modules called ${Something}x::* as
add-ons to $Something.
And yes, for DBI and other it's 'x', elsewhere it's often 'X'.
For clarification, are you saying that my driver should be called
DBDx::XML? The reason I ask is that all the DBDx::* modules I could
find seem to be extensions to DBI or things that use DBI, rather than
DBI drivers or backends.
Not exactly. I'm rather saying that drivers of specific types (i.e.
behave in specific ways) do follow a standardized naming convention.
It's then up to you to decide if your module resembles those others, or not.
Also would that confuse with the existing DBIx::XML code? That does
something entirely different.
Indeed it would. So don't do that :-).
--
Ron Savage - savage.net.au
Re: DBD::XML
On 19/8/16 11:51, Tim Bunce wrote:
On Fri, Aug 19, 2016 at 10:09:45AM -0400, Nigel Horne wrote:
On 8/19/16 9:56 AM, Tim Bunce wrote:
On Fri, Aug 19, 2016 at 09:30:32AM -0400, Nigel Horne wrote:
Apart from one change I need to make in terms of column names, I'm pretty
much ready to start working on a 0.01 CPAN release. It's read-only, but
that's all I need. How do I set about requesting driver registration, or is
this mentioning enough?
Probably :)
But I wonder about the name. "DBD::XML" seems to be a bold name,
implying that it's _the_ DBI interface for data stored in XML files.
Of course the same kind of issue applies to many other drivers,
so it's not a major concern, but does seem worth dicussing.
I'm more than happy to entertain other names if you have any suggestions.
I've some random questions and observations below...
So, here's the example I've started with to get the code basic interface
going and tested. The code I have works with this trivial example.
data/person.xml:
Nigel Horne
n...@bandsman.co.uk
A N Other
nob...@example.com
Does that format ('table', 'row', 'id') correspond with a known XML Schema?
Nope, that's me creating random test data to poke around.
use DBD::XML;
(Ideally users shouldn't need to use the driver module explicitly.)
I'm assuming after registration that would go away, or am I wrong?
my $dbh = DBI->connect('dbi:XML(RaiseError => 1):');
$dbh->func('person', 'XML', "$Bin/../data/person.xml", 'ad_import'); # to be
replaced with xml_import once the driver has been registered
I presume ad_import comes from DBD::AnyData. Is that 'inspired by',
or 'is a fork of', or 'using under the hood'?
"Pinched from" to get a bootstrap while I'm developing before registration.
my $sth = $dbh->prepare("SELECT * FROM person");
$sth->execute();
while (my $href = $sth->fetchrow_hashref()) {
my $d = Data::Dumper->new([$href]);
print "got data:\n", $d->Dump();
}
($sth->dump_results can be handy for little example scripts.)
Thanks for the pointer - that's useful to know.
Are any other XML Schema supported, or supportable?
I hope so, once I'm ready to create more test data beyond the trivial
stuff I'm using to get started.
Is the XML and/or the parsed data loaded into memory or does each
$sth->fetch call pull the next chunk from the XML parser?
I'm hoping to do chunk by chunk, but that's not done yet.
In other words, can it read files larger than the available memory?
(Not related to the naming, just curious :)
I really hope so, but not yet. I need to walk before I can run :-)
-Nigel
Tim.
Fwd: Re: DBD::XML
Hi Ron,
On 19/8/16 20:24, Ron Savage wrote:
Hi Nigel
On 20/08/16 01:51, Tim Bunce wrote:
On Fri, Aug 19, 2016 at 10:09:45AM -0400, Nigel Horne wrote:
On 8/19/16 9:56 AM, Tim Bunce wrote:
On Fri, Aug 19, 2016 at 09:30:32AM -0400, Nigel Horne wrote:
[snip]
But I wonder about the name. "DBD::XML" seems to be a bold name,
implying that it's _the_ DBI interface for data stored in XML files.
Of course the same kind of issue applies to many other drivers,
so it's not a major concern, but does seem worth dicussing.
I'm more than happy to entertain other names if you have any
suggestions.
As a rule, we have DBI (there's just one) and anything it uses
(DBI::*), and then we have DBIx::* for all our additions in thefield.
That is, we all agree to explicitly avoid using DBI::*. Even drivers
loaded by DBI are called DBD::Pg, DBD::mysql, DBD::SQLite, etc.
This usage of $ABCx or $AbcX is a wide-spread convention. E.g.
Marpa::* is exclusively used by Jeffrey Kegler, and all ours are
MarpaX::*. But there are many, many modules called ${Something}x::* as
add-ons to $Something.
And yes, for DBI and other it's 'x', elsewhere it's often 'X'.
For clarification, are you saying that my driver should be called
DBDx::XML? The reason I ask is that all the DBDx::* modules I could
find seem to be extensions to DBI or things that use DBI, rather than
DBI drivers or backends.
Also would that confuse with the existing DBIx::XML code? That does
something entirely different.
-Nigel
Re: DBD::XML
Hi Nigel I'm more than happy to entertain other names if you have any suggestions. See also http://prepan.org/ for a place to discuss module naming -- Ron Savage - savage.net.au
Re: DBD::XML
Hi Nigel
On 20/08/16 01:51, Tim Bunce wrote:
On Fri, Aug 19, 2016 at 10:09:45AM -0400, Nigel Horne wrote:
On 8/19/16 9:56 AM, Tim Bunce wrote:
On Fri, Aug 19, 2016 at 09:30:32AM -0400, Nigel Horne wrote:
[snip]
But I wonder about the name. "DBD::XML" seems to be a bold name,
implying that it's _the_ DBI interface for data stored in XML files.
Of course the same kind of issue applies to many other drivers,
so it's not a major concern, but does seem worth dicussing.
I'm more than happy to entertain other names if you have any suggestions.
As a rule, we have DBI (there's just one) and anything it uses (DBI::*),
and then we have DBIx::* for all our additions in thefield. That is, we
all agree to explicitly avoid using DBI::*. Even drivers loaded by DBI
are called DBD::Pg, DBD::mysql, DBD::SQLite, etc.
This usage of $ABCx or $AbcX is a wide-spread convention. E.g. Marpa::*
is exclusively used by Jeffrey Kegler, and all ours are MarpaX::*. But
there are many, many modules called ${Something}x::* as add-ons to
$Something.
And yes, for DBI and other it's 'x', elsewhere it's often 'X'.
--
Ron Savage - savage.net.au
Re: DBD::XML
On Fri, Aug 19, 2016 at 10:09:45AM -0400, Nigel Horne wrote:
> On 8/19/16 9:56 AM, Tim Bunce wrote:
> > On Fri, Aug 19, 2016 at 09:30:32AM -0400, Nigel Horne wrote:
> > >
> > > Apart from one change I need to make in terms of column names, I'm pretty
> > > much ready to start working on a 0.01 CPAN release. It's read-only, but
> > > that's all I need. How do I set about requesting driver registration, or
> > > is
> > > this mentioning enough?
> > Probably :)
> >
> > But I wonder about the name. "DBD::XML" seems to be a bold name,
> > implying that it's _the_ DBI interface for data stored in XML files.
> > Of course the same kind of issue applies to many other drivers,
> > so it's not a major concern, but does seem worth dicussing.
>
> I'm more than happy to entertain other names if you have any suggestions.
I've some random questions and observations below...
> So, here's the example I've started with to get the code basic interface
> going and tested. The code I have works with this trivial example.
>
> data/person.xml:
>
>
>
>
> Nigel Horne
> n...@bandsman.co.uk
>
>
> A N Other
> nob...@example.com
>
>
Does that format ('table', 'row', 'id') correspond with a known XML Schema?
> use DBD::XML;
(Ideally users shouldn't need to use the driver module explicitly.)
> my $dbh = DBI->connect('dbi:XML(RaiseError => 1):');
> $dbh->func('person', 'XML', "$Bin/../data/person.xml", 'ad_import'); # to be
> replaced with xml_import once the driver has been registered
I presume ad_import comes from DBD::AnyData. Is that 'inspired by',
or 'is a fork of', or 'using under the hood'?
> my $sth = $dbh->prepare("SELECT * FROM person");
> $sth->execute();
>
> while (my $href = $sth->fetchrow_hashref()) {
> my $d = Data::Dumper->new([$href]);
> print "got data:\n", $d->Dump();
> }
($sth->dump_results can be handy for little example scripts.)
Are any other XML Schema supported, or supportable?
Is the XML and/or the parsed data loaded into memory or does each
$sth->fetch call pull the next chunk from the XML parser?
In other words, can it read files larger than the available memory?
(Not related to the naming, just curious :)
Tim.
Re: DBD::XML
On 8/19/16 9:56 AM, Tim Bunce wrote:
On Fri, Aug 19, 2016 at 09:30:32AM -0400, Nigel Horne wrote:
Ron,
I've started working on a DBD::XML driver, and the first pass is looking
good. I'm doing this because of the demise of DBD::AnyData, and
DBD::AnyData2 isn't ready yet, so until it is I wanted XML support.
Before I go any further, is anyone else working on something similar or
is there something already out there? I don't want to re-invent the
wheel.
It sounds vaguely like my
https://metacpan.org/release/DBIx-Admin-BackupRestore.
Excellent, thanks so much for the pointer. I'll take a look and see.
Apart from one change I need to make in terms of column names, I'm pretty
much ready to start working on a 0.01 CPAN release. It's read-only, but
that's all I need. How do I set about requesting driver registration, or is
this mentioning enough?
Probably :)
But I wonder about the name. "DBD::XML" seems to be a bold name,
implying that it's _the_ DBI interface for data stored in XML files.
Of course the same kind of issue applies to many other drivers,
so it's not a major concern, but does seem worth dicussing.
I'm more than happy to entertain other names if you have any suggestions.
So, here's the example I've started with to get the code basic interface
going and tested. The code I have works with this trivial example.
data/person.xml:
Nigel Horne
n...@bandsman.co.uk
A N Other
nob...@example.com
bin/xml:
#!/usr/bin/env perl
use warnings;
use strict;
use autodie qw(:all);
use Data::Dumper;
use FindBin qw($Bin);
use lib "$Bin/../lib";
use DBD::XML;
print "Test 1 - import from file\n";
my $dbh = DBI->connect('dbi:XML(RaiseError => 1):');
$dbh->func('person', 'XML', "$Bin/../data/person.xml", 'ad_import'); #
to be replaced with xml_import once the driver has been registered
my $sth = $dbh->prepare("SELECT * FROM person");
$sth->execute();
while (my $href = $sth->fetchrow_hashref()) {
my $d = Data::Dumper->new([$href]);
print "got data:\n", $d->Dump();
}
print "Test 2 - import from string\n";
$dbh = DBI->connect('dbi:XML(RaiseError => 1):');
$dbh->func('person2', 'XML', [], 'ad_import');
$sth = $dbh->prepare("Select email FROM person2 WHERE name = 'Nigel
Horne'");
$sth->execute();
while (my $href = $sth->fetchrow_hashref()) {
my $d = Data::Dumper->new([$href]);
print "got data:\n", $d->Dump();
}
__DATA__
Nigel Horne
n...@concert-bands.co.uk
A N Other
someb...@example.com
Tim.
-Nigel
--
Nigel Horne
Conductor: Rockville Brass Band, Washington Metropolitan GSO
@nigelhorne | fb/nigel.horne | bandsman.co.uk | concert-bands.co.uk |
www.nigelhorne.com
Unless it's for my eyes only, please use "reply all"
smime.p7s
Description: S/MIME Cryptographic Signature
Re: DBD::XML
On Fri, Aug 19, 2016 at 09:30:32AM -0400, Nigel Horne wrote: > Ron, > > > I've started working on a DBD::XML driver, and the first pass is looking > > > good. I'm doing this because of the demise of DBD::AnyData, and > > > DBD::AnyData2 isn't ready yet, so until it is I wanted XML support. > > > > > > Before I go any further, is anyone else working on something similar or > > > is there something already out there? I don't want to re-invent the > > > wheel. > > > > It sounds vaguely like my > > https://metacpan.org/release/DBIx-Admin-BackupRestore. > > Excellent, thanks so much for the pointer. I'll take a look and see. > > Apart from one change I need to make in terms of column names, I'm pretty > much ready to start working on a 0.01 CPAN release. It's read-only, but > that's all I need. How do I set about requesting driver registration, or is > this mentioning enough? Probably :) But I wonder about the name. "DBD::XML" seems to be a bold name, implying that it's _the_ DBI interface for data stored in XML files. Of course the same kind of issue applies to many other drivers, so it's not a major concern, but does seem worth dicussing. Tim.
Re: DBD::XML
Ron, I've started working on a DBD::XML driver, and the first pass is looking good. I'm doing this because of the demise of DBD::AnyData, and DBD::AnyData2 isn't ready yet, so until it is I wanted XML support. Before I go any further, is anyone else working on something similar or is there something already out there? I don't want to re-invent the wheel. It sounds vaguely like my https://metacpan.org/release/DBIx-Admin-BackupRestore. Excellent, thanks so much for the pointer. I'll take a look and see. Apart from one change I need to make in terms of column names, I'm pretty much ready to start working on a 0.01 CPAN release. It's read-only, but that's all I need. How do I set about requesting driver registration, or is this mentioning enough? -Nigel -- Nigel Horne Conductor: Rockville Brass Band, Washington Metropolitan GSO @nigelhorne | fb/nigel.horne | bandsman.co.uk | concert-bands.co.uk | www.nigelhorne.com Unless it's for my eyes only, please use "reply all" smime.p7s Description: S/MIME Cryptographic Signature
Re: DBD::XML
Hi Nigel On 19/08/16 05:49, Nigel Horne wrote: I've started working on a DBD::XML driver, and the first pass is looking good. I'm doing this because of the demise of DBD::AnyData, and DBD::AnyData2 isn't ready yet, so until it is I wanted XML support. Before I go any further, is anyone else working on something similar or is there something already out there? I don't want to re-invent the wheel. It sounds vaguely like my https://metacpan.org/release/DBIx-Admin-BackupRestore. -- Ron Savage - savage.net.au
