Anyone using Berkley XML DB w/Perl (of course)...?

Discussion in 'Perl Misc' started by Chris, Feb 9, 2004.

  1. Chris

    Chris Guest

    I'm trying to find some Perl API support (read "CPAN module") for using
    Sleepcat's Berkley XML DB, but I'm coming up blank. Sleepcat's web site
    is Java and C++ centric and I see no Perl information there though an
    article I read on XML DB claims there is Perl support. Googling for a
    suitable module produced nothing of interest, not to mention such
    searching is muddied by www.xmldb.org which uses a lot of Perl-like
    "XML::DB" notation.

    It would appear that Berkley's XML DB coupled with XML::Dumper poses
    some interesting possibilities for run-time object persistence between
    client and server platforms... tantalizing to say the least.

    Surely I would be spared having to download the Java support and convert
    to Perl modules... 8-( I guess I can try their message list, but
    thought a quick note here would maybe turn up something solid.

    Chris
    -----
    Chris Olive
    chris -at- --spammers-continue-to-be-vermin-- technologEase -dot- com
    http://www.technologEase.com
    (pronounced "technologies")
     
    Chris, Feb 9, 2004
    #1
    1. Advertising

  2. Chris

    Vetle Roeim Guest

    *
    > I'm trying to find some Perl API support (read "CPAN module") for
    > using Sleepcat's Berkley XML DB, but I'm coming up blank.


    You're not going to find it on CPAN, unfortunately. To install it, I
    downloaded the source code, compiled it, and then installed the Perl
    module from dbxml-1.2.0/src/perl.

    Good luck.


    [...]

    --
    #!/usr/bin/vr
     
    Vetle Roeim, Feb 9, 2004
    #2
    1. Advertising

  3. Chris

    Robert Guest

    Chris wrote:

    > I'm trying to find some Perl API support (read "CPAN module") for using
    > Sleepcat's Berkley XML DB, but I'm coming up blank. Sleepcat's web site
    > is Java and C++ centric and I see no Perl information there though an
    > article I read on XML DB claims there is Perl support. Googling for a
    > suitable module produced nothing of interest, not to mention such
    > searching is muddied by www.xmldb.org which uses a lot of Perl-like
    > "XML::DB" notation.
    >
    > It would appear that Berkley's XML DB coupled with XML::Dumper poses
    > some interesting possibilities for run-time object persistence between
    > client and server platforms... tantalizing to say the least.
    >
    > Surely I would be spared having to download the Java support and convert
    > to Perl modules... 8-( I guess I can try their message list, but
    > thought a quick note here would maybe turn up something solid.
    >
    > Chris
    > -----


    And if someone does create a binary (esp. for ActiveState) please share
    it. :)
     
    Robert, Feb 9, 2004
    #3
  4. Chris

    Ben Morrow Guest

    Vetle Roeim <> wrote:
    > *
    > > I'm trying to find some Perl API support (read "CPAN module") for
    > > using Sleepcat's Berkley XML DB, but I'm coming up blank.

    >
    > You're not going to find it on CPAN, unfortunately. To install it, I
    > downloaded the source code, compiled it, and then installed the Perl
    > module from dbxml-1.2.0/src/perl.


    Having taken a look at that: bleech. Is it *quite* necessary to
    trample on that many different (including top-level and pragmatic)
    namespaces? And is it really necessary to have the interface be so
    C++ish?

    You may be better off writing your own wrapper: it shouldn't be *that*
    hard...

    Ben

    --
    For the last month, a large number of PSNs in the Arpa[Inter-]net have been
    reporting symptoms of congestion ... These reports have been accompanied by an
    increasing number of user complaints ... As of June,... the Arpanet contained
    47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] *
     
    Ben Morrow, Feb 10, 2004
    #4
  5. Chris

    Chris Guest

    Robert wrote:
    > Chris wrote:
    >
    >> I'm trying to find some Perl API support (read "CPAN module") for
    >> using Sleepcat's Berkley XML DB, but I'm coming up blank. Sleepcat's
    >> web site is Java and C++ centric and I see no Perl information there
    >> though an article I read on XML DB claims there is Perl support.
    >> Googling for a suitable module produced nothing of interest, not to
    >> mention such searching is muddied by www.xmldb.org which uses a lot of
    >> Perl-like "XML::DB" notation.
    >>
    >> It would appear that Berkley's XML DB coupled with XML::Dumper poses
    >> some interesting possibilities for run-time object persistence between
    >> client and server platforms... tantalizing to say the least.
    >>
    >> Surely I would be spared having to download the Java support and
    >> convert to Perl modules... 8-( I guess I can try their message list,
    >> but thought a quick note here would maybe turn up something solid.
    >>
    >> Chris
    >> -----

    >
    >
    > And if someone does create a binary (esp. for ActiveState) please share
    > it. :)


    Well, if I combine all the sentiments, it seems that maybe a more
    Perl-like wrapper/module could be in order. I doubt I will have the
    time to look at it seriously for a little while yet, but I might venture
    into it here before too long. It seems there might actually be some
    interest in that sort of thing, myself included. And I *was* wanting it
    initially for ActiveState in the immediate, even though I tend to prefer
    Linux. I'd *really* like to play with this XML DB some... The object
    persistence this could bring to some stateless apps would be fun to play
    with over and above sessions (CGI::Sessions, etc.).

    I'll download the Linux source and follow the lead I was given and see
    where that takes me. Should have thought to do that (check out the
    Linux source) already.

    Thanks all,
    Chris
    -----
    Chris Olive
    chris -at- --spammers-are-bogus-- technologEase -dot- com
    http://www.technologEase.com
    (pronounced "technologies")
     
    Chris, Feb 10, 2004
    #5
  6. Chris

    Vetle Roeim Guest

    * Ben Morrow
    > Vetle Roeim <> wrote:
    >> *
    >> > I'm trying to find some Perl API support (read "CPAN module") for
    >> > using Sleepcat's Berkley XML DB, but I'm coming up blank.

    >>
    >> You're not going to find it on CPAN, unfortunately. To install it, I
    >> downloaded the source code, compiled it, and then installed the Perl
    >> module from dbxml-1.2.0/src/perl.

    >
    > Having taken a look at that: bleech. Is it *quite* necessary to
    > trample on that many different (including top-level and pragmatic)
    > namespaces? And is it really necessary to have the interface be so
    > C++ish?


    I didn't like it either. There exists a set of
    XML::DB::Database-modules that provide interfaces to a couple of XML
    databases. I haven't checked them out, though.

    They may provide a better interface.


    [...]

    --
    #!/usr/bin/vr
     
    Vetle Roeim, Feb 10, 2004
    #6
  7. "Ben Morrow" <> wrote in message
    news:c097lg$ajg$...
    >
    > Vetle Roeim <> wrote:
    > > *
    > > > I'm trying to find some Perl API support (read "CPAN module") for
    > > > using Sleepcat's Berkley XML DB, but I'm coming up blank.

    > >
    > > You're not going to find it on CPAN, unfortunately. To install it, I
    > > downloaded the source code, compiled it, and then installed the Perl
    > > module from dbxml-1.2.0/src/perl.

    >
    > Having taken a look at that: bleech.


    Thanks for the constructive feedback Ben. :)

    Seriously though, I'd be interested to hear in a bit more detail what you,
    and anoyone else in this thread, think about the current interface, both
    good and bad. To date, this is the first negative feedback I've received.

    > Is it *quite* necessary to
    > trample on that many different (including top-level and pragmatic)
    > namespaces?


    Yes. There are quite a few objects exposed by the dbxml interface. If you
    want those C++ objects to map to Perl objects, you need a namespace for
    each.

    I didn't think I was reusing any pragmatic namespaces - which are you
    thinking of?

    > And is it really necessary to have the interface be so C++ish?


    Well it is an interface to a C++ library after all :)

    When I wrote the interface, it seemed obvious make it mirror the OO
    interface that dbxml was already provinding.

    > You may be better off writing your own wrapper: it shouldn't be *that*
    > hard...


    Absolutely, TMTOWTDI.

    Paul
     
    Paul Marquess, Feb 10, 2004
    #7
  8. Chris

    Ben Morrow Guest

    "Paul Marquess" <> wrote:
    > "Ben Morrow" <> wrote in message
    > news:c097lg$ajg$...
    > >
    > > Vetle Roeim <> wrote:
    > > > *
    > > > You're not going to find it on CPAN, unfortunately. To install it, I
    > > > downloaded the source code, compiled it, and then installed the Perl
    > > > module from dbxml-1.2.0/src/perl.

    > >
    > > Having taken a look at that: bleech.

    >
    > Thanks for the constructive feedback Ben. :)


    Sorry, that was a little rude... :(.

    > Seriously though, I'd be interested to hear in a bit more detail what you,
    > and anoyone else in this thread, think about the current interface, both
    > good and bad. To date, this is the first negative feedback I've received.
    >
    > > Is it *quite* necessary to
    > > trample on that many different (including top-level and pragmatic)
    > > namespaces?

    >
    > Yes. There are quite a few objects exposed by the dbxml interface. If you
    > want those C++ objects to map to Perl objects, you need a namespace for
    > each.


    Yes, but you don't need to give them the same names as the C++ classes
    had. What happens if someone's using another XML module as well (not
    at all unlikely), and that happened to also define the package
    XmlDocument?

    Indeed, the C++ classes are all in the namespace DbXml, which will
    keep them from conflicting with any other XmlDocument class people
    might be using. I would have given the classes names like
    DB::XML::Container, and kept all the names below DB::XML, or
    something.

    > I didn't think I was reusing any pragmatic namespaces - which are you
    > thinking of?


    std::exception. All lower-case top-level namespaces are reserved for
    pragmata. The whole exception-handling logic seems unnecessarily
    complex: what's wrong with

    package DB::XML::Exception;

    our @EXPORT = qw/catch/;

    sub catch {
    my $type = shift;
    UNIVERSAL::isa($@, __PACKAGE__) and $@->{type} eq $type
    and return $@;
    return;
    }

    package main;

    eval {
    ...
    }
    if (my $e = catch 'DbException') {
    ...
    }

    or

    if (ref $@ and $a->isa(DB::XML::X::DbDeadlock)) {

    or even

    if ($@ and $!{EDEADLK}) {

    , which I at least find much more Perlish? The mapping seems pretty
    clear:

    DbDeadlockException EDEADLK
    DbException is never thrown
    DbLockNotGrantedException EWOULDBLOCK
    DbRunRecoveryException EINVAL

    etc. XmlException could probably just throw a string.

    I realise this means you can't just get the typemap to do all the work
    :).

    > > And is it really necessary to have the interface be so C++ish?

    >
    > Well it is an interface to a C++ library after all :)


    True... your BerkeleyDB module, though, provides a much more Perl-ish
    interface to the C db libraries.

    > > You may be better off writing your own wrapper: it shouldn't be *that*
    > > hard...

    >
    > Absolutely, TMTOWTDI.


    Well, yes :).

    Ben

    --
    Musica Dei donum optimi, trahit homines, trahit deos. |
    Musica truces molit animos, tristesque mentes erigit. |
    Musica vel ipsas arbores et horridas movet feras. |
     
    Ben Morrow, Feb 10, 2004
    #8
  9. "Ben Morrow" <> wrote in message
    news:c0ap5d$95u$...
    >
    > "Paul Marquess" <> wrote:
    > > "Ben Morrow" <> wrote in message
    > > news:c097lg$ajg$...
    > > >
    > > > Vetle Roeim <> wrote:
    > > > > *
    > > > > You're not going to find it on CPAN, unfortunately. To install

    it, I
    > > > > downloaded the source code, compiled it, and then installed the

    Perl
    > > > > module from dbxml-1.2.0/src/perl.
    > > >
    > > > Having taken a look at that: bleech.

    > >
    > > Thanks for the constructive feedback Ben. :)

    >
    > Sorry, that was a little rude... :(.
    >
    > > Seriously though, I'd be interested to hear in a bit more detail what

    you,
    > > and anoyone else in this thread, think about the current interface, both
    > > good and bad. To date, this is the first negative feedback I've

    received.
    > >
    > > > Is it *quite* necessary to
    > > > trample on that many different (including top-level and pragmatic)
    > > > namespaces?

    > >
    > > Yes. There are quite a few objects exposed by the dbxml interface. If

    you
    > > want those C++ objects to map to Perl objects, you need a namespace for
    > > each.

    >
    > Yes, but you don't need to give them the same names as the C++ classes
    > had.


    I assume your issue isn't really that I've used the same names as the C++
    classes, but that I've put them in a top-level namespace? Ignoring namespace
    issues for a moment, reusing the C++ class names seems to make perfect
    sense.

    > What happens if someone's using another XML module as well (not
    > at all unlikely), and that happened to also define the package
    > XmlDocument?
    >
    > Indeed, the C++ classes are all in the namespace DbXml, which will
    > keep them from conflicting with any other XmlDocument class people
    > might be using. I would have given the classes names like
    > DB::XML::Container, and kept all the names below DB::XML, or
    > something.


    There is always a problem of clashing namespaces, and I accept that by using
    quite a few top-level names I'm increasing that possibility. I'm not
    convinced
    it's as big a problem as you make out, but I'll have a think about this
    one - my preferred choice would be to go for DbXml:: as the common prefix
    for all the class names.

    > > I didn't think I was reusing any pragmatic namespaces - which are you
    > > thinking of?

    >
    > std::exception. All lower-case top-level namespaces are reserved for
    > pragmata.


    Indeed it is.

    > The whole exception-handling logic seems unnecessarily
    > complex: what's wrong with
    >
    > package DB::XML::Exception;
    >
    > our @EXPORT = qw/catch/;
    >
    > sub catch {
    > my $type = shift;
    > UNIVERSAL::isa($@, __PACKAGE__) and $@->{type} eq $type
    > and return $@;
    > return;
    > }
    >
    > package main;
    >
    > eval {
    > ...
    > }
    > if (my $e = catch 'DbException') {
    > ...
    > }


    Ignoring the hoops I may have jumped through to implement my version of
    "catch", from an end users point of view, that looks very like what I've
    already implemented.

    One thing on my todo list is to provide a shortcut to get at the exception
    string. I'll probably do it by overloading the stringification operator.

    eval {
    ...
    };

    if (my $e = catch XmlException) {
    print "got this exception $e\n";
    }

    > or
    >
    > if (ref $@ and $a->isa(DB::XML::X::DbDeadlock)) {


    Personally, I hate that syntax in user code, although it should already work
    with my current
    interface. :)

    > or even
    >
    > if ($@ and $!{EDEADLK}) {
    >
    > , which I at least find much more Perlish? The mapping seems pretty
    > clear:
    >
    > DbDeadlockException EDEADLK
    > DbException is never thrown
    > DbLockNotGrantedException EWOULDBLOCK
    > DbRunRecoveryException EINVAL
    >
    > etc. XmlException could probably just throw a string.


    If I was going to go down that route, I'd rip out the exception handling
    interface and use return codes instead.

    > I realise this means you can't just get the typemap to do all the work
    > :).


    Quite so :)

    > > > And is it really necessary to have the interface be so C++ish?

    > >
    > > Well it is an interface to a C++ library after all :)

    >
    > True... your BerkeleyDB module, though, provides a much more Perl-ish
    > interface to the C db libraries.


    I think there are a couple of reasons for the difference in the interfaces
    I created. The first is simply down to the fact that the native dbxml
    interface is C++, while Berkeley DB is C.

    The other reason I've deliberately kept close to the C++ interface was to
    future proof myself. The dbxml library is still quite young and has already
    changed a couple of times -- I don't want to paint myself into any corner
    with interface decisions.

    cheers
    Paul
     
    Paul Marquess, Feb 11, 2004
    #9
  10. Chris

    Ben Morrow Guest

    "Paul Marquess" <> wrote:
    > "Ben Morrow" <> wrote in message
    > news:c0ap5d$95u$...
    > > Yes, but you don't need to give them the same names as the C++ classes
    > > had.

    >
    > I assume your issue isn't really that I've used the same names as the C++
    > classes, but that I've put them in a top-level namespace?


    Of course.

    > Ignoring namespace issues for a moment, reusing the C++ class names
    > seems to make perfect sense.


    Well, yes... it depends on who's point of view your coming from. There
    are rather different conventions for how things should be named in C++
    and Perl (in particular, XML-related and DB-related modules in Perl
    *always* spell them XML and DB rather than Xml and Db), so none of
    those names would have been invented by someone writing a DBXML
    library from scratch in Perl. If you are more concerned that someone
    with familiarity with this library in C++ should not be lost when
    using it in Perl, then stick to the C++ names. If you are more
    concerned that someone used to Perl should not be confused when coming
    to this module as a Perl module, with no knowledge of or interest in
    the underlying C++ library, then more Perlish names would be better.

    > > What happens if someone's using another XML module as well (not
    > > at all unlikely), and that happened to also define the package
    > > XmlDocument?
    > >
    > > Indeed, the C++ classes are all in the namespace DbXml, which will
    > > keep them from conflicting with any other XmlDocument class people
    > > might be using. I would have given the classes names like
    > > DB::XML::Container, and kept all the names below DB::XML, or
    > > something.

    >
    > There is always a problem of clashing namespaces, and I accept that by using
    > quite a few top-level names I'm increasing that possibility.


    The point of the CPAN namespace-registration system is that it gets
    rid of the problem. People register their namespaces, and stay within
    them, and then we don't get conflicts. You will note that the PAUSE
    module-list registration form specifically says that you must provide
    good reasons why you need a new top-level namespace.

    > I'm not convinced it's as big a problem as you make out,


    Are you not? I think that as things stand there may not be much of a
    problem, because 1. noone else would use those C++ish names and
    2. everyone else will follow the rules and not use top-level names
    when they don't need to. I don't think these are good things to rely
    on.

    As I said, consider someone using some other XML module: say, to get
    XML out of their database and insert it into some other system. If the
    name XmlDocument were considered fair game, you must admit it's not at
    all unlikely that this other module author would have used it as
    well. The only way there is any chance of avoiding clashes is if
    everyone sticks within their own namespace.

    > but I'll have a think about this
    > one - my preferred choice would be to go for DbXml:: as the common prefix
    > for all the class names.


    OK... it doesn't matter what you choose, as long as you choose something.

    > > The whole exception-handling logic seems unnecessarily
    > > complex: what's wrong with
    > >
    > > package DB::XML::Exception;
    > >
    > > our @EXPORT = qw/catch/;
    > >
    > > sub catch {
    > > my $type = shift;
    > > UNIVERSAL::isa($@, __PACKAGE__) and $@->{type} eq $type
    > > and return $@;
    > > return;
    > > }
    > >
    > > package main;
    > >
    > > eval {
    > > ...
    > > }
    > > if (my $e = catch 'DbException') {
    > > ...
    > > }

    >
    > Ignoring the hoops I may have jumped through to implement my version of
    > "catch", from an end users point of view, that looks very like what I've
    > already implemented.


    That was the point: it's almost identical, and doesn't stomp on about
    6 top-level names.

    > One thing on my todo list is to provide a shortcut to get at the exception
    > string. I'll probably do it by overloading the stringification operator.
    >
    > eval {
    > ...
    > };
    >
    > if (my $e = catch XmlException) {
    > print "got this exception $e\n";
    > }


    Oh, does it not already?... I'd kinda assumed it would :).

    > > or
    > >
    > > if (ref $@ and $a->isa(DB::XML::X::DbDeadlock)) {

    >
    > Personally, I hate that syntax in user code, although it should
    > already work with my current interface. :)


    Yeah, but it's (one of) the Perl idiom(s) for exception
    catching. Someone reading that code will see instantly what it
    does. Inventing random new interfaces violates the principle of least
    surprise.

    > > or even
    > >
    > > if ($@ and $!{EDEADLK}) {
    > >
    > > , which I at least find much more Perlish? The mapping seems pretty
    > > clear:
    > >
    > > DbDeadlockException EDEADLK
    > > DbException is never thrown
    > > DbLockNotGrantedException EWOULDBLOCK
    > > DbRunRecoveryException EINVAL
    > >
    > > etc. XmlException could probably just throw a string.

    >
    > If I was going to go down that route, I'd rip out the exception handling
    > interface and use return codes instead.


    Yup.... personally, I'd not object to that. Remember, people can
    always put it back with use fatal. One of the things I dislike about
    Java (I've never written any (modern) C++) is that everything has to
    be wrapped in a try/catch block.

    > > > > And is it really necessary to have the interface be so C++ish?
    > > >
    > > > Well it is an interface to a C++ library after all :)

    > >
    > > True... your BerkeleyDB module, though, provides a much more Perl-ish
    > > interface to the C db libraries.

    >
    > I think there are a couple of reasons for the difference in the interfaces
    > I created. The first is simply down to the fact that the native dbxml
    > interface is C++, while Berkeley DB is C.


    ....yes...? Neither is Perl, despite the superficial similarities
    between C++'s and Perl's OO.

    > The other reason I've deliberately kept close to the C++ interface was to
    > future proof myself. The dbxml library is still quite young and has already
    > changed a couple of times -- I don't want to paint myself into any corner
    > with interface decisions.


    This is, of course, sensible. Might I respectfully suggest a strategy
    of having a DbXml::Native module that is just a very thin XS wrapper
    around the C++ library, and then making DbXml implemented in Perl on
    top of that?

    Ben

    --
    $.=1;*g=sub{print@_};sub r($$\$){my($w,$x,$y)=@_;for(keys%$x){/main/&&next;*p=$
    $x{$_};/(\w)::$/&&(r($w.$1,$x.$_,$y),next);$y eq\$p&&&g("$w$_")}};sub t{for(@_)
    {$f&&($_||&g(" "));$f=1;r"","::",$_;$_&&&g(chr(0012))}};t #
    $J::u::s::t, $a::n::eek:::t::h::e::r, $P::e::r::l, $h::a::c::k::e::r, $.
     
    Ben Morrow, Feb 11, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gil
    Replies:
    2
    Views:
    355
  2. Replies:
    3
    Views:
    262
  3. Peter Keller

    Cannot build perl 5.8.0 with Berkley DB 4.1.15

    Peter Keller, Jul 8, 2003, in forum: Perl Misc
    Replies:
    2
    Views:
    103
    Peter Keller
    Jul 9, 2003
  4. Perl scripting course

    , Feb 18, 2005, in forum: Perl Misc
    Replies:
    2
    Views:
    136
    Alan Mead
    Feb 19, 2005
  5. Uri Guttman

    Re: Help Review Perl Course

    Uri Guttman, Aug 11, 2013, in forum: Perl Misc
    Replies:
    1
    Views:
    154
    J├╝rgen Exner
    Aug 11, 2013
Loading...

Share This Page