I think I'm going to end up going the route of a new module called DBD::Object.
While AnyData seems like a good fit, the whole table vs. database thing seems
to hamper that choice too much. Besides, if we're talking about multiple
tables, it's pretty much a database at that point, anyway.
On Mon, 12 Sep 2011 17:29:57 +, Byrd, Brendan
byr...@insightcom.com wrote:
DBD::NestedHash - This could also be its own Perl module within CPAN.
However, the hash to table conversion is such a thin wrapper around
DBD::AnyData that it just seems to make more sense to actually tie it
into
Would it be an actual DBI driver?
Could you post some examples or docs?
I'm uncomfortable with it having such a generic name.
Two words after the DBD would be better.
Tim.
On Wed, Sep 21, 2011 at 02:58:09AM +, Byrd, Brendan wrote:
I think I'm going to end up going the route of a new
On Wed, Sep 21, 2011 at 03:17:53PM +, Byrd, Brendan wrote:
It basically takes whatever Perl tree object you throw at it and turns
it into a database.
Cool.
Given that description I'd suggest a name like DBD::TreeDataMumble
e.g., DBD::TreeDataWrapper with tdw_ as the prefix.
Tim.
This
DBI peeps,
Sorry for the delayed response, I've been busy, looking to reply to this thread
now.
On Sep 9, 2011, at 8:06 PM, Greg Sabino Mullane wrote:
One thing I see bandied about a lot is that Perl 5.14 is highly preferred.
However, it's not clear exactly what the gains are and how bad
On Sep 10, 2011, at 7:44 AM, Lyle wrote:
Right now 5.8 is the required minimum for DBI: should we consider bumping
this?
I know a lot of servers in the wild are still running RHEL5 and it's
variants, which are stuck on 5.8 in the standard package management. The new
RHEL6 only has
On Sep 10, 2011, at 3:08 AM, Martin J. Evans wrote:
I'm not sure any change is required to DBI to support unicode. As far as I'm
aware unicode already works with DBI if the DBDs do the right thing.
Right, but the problem is that, IME, none of them do the right thing. As I
said, I've
Depends on your definition of actual. Or for that matter, your definition of
Object.
I have some draft code on the beginning of this thread. It basically takes
whatever Perl tree object you throw at it and turns it into a database. This
is achieved with a custom recursive sub to normalize
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I believe that DBI should go away as an actual piece of code and instead be
replaced by an API specification document, taking PSGI as inspiration.
I'm having a hard time envisioning how this would work in practice. What I
see is lots of
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
...
And maybe that's the default. But I should be able to tell it to be pedantic
when the
data is known to be bad (see, for example data from an SQL_ASCII-encoded
PostgreSQL database).
...
DBD::Pg's approach is currently broken. Greg is
On Sep 21, 2011, at 1:52 PM, Greg Sabino Mullane wrote:
Since nobody has actally defined a specific interface yet, let me throw out a
straw man. It may look familiar :)
===
* $h-{unicode_flag}
If this is set on, data returned from the database is assumed to be UTF-8,
and
the utf8
Greg Sabino Mullane wrote:
I believe that DBI should go away as an actual piece of code and instead be
replaced by an API specification document, taking PSGI as inspiration.
I'm having a hard time envisioning how this would work in practice. What I
see is lots of duplicated code across the
On Wed, Sep 21, 2011 at 7:27 PM, Darren Duncan
As for DBMS-specific hacks
Another possible approach would be a strict interface that only allows
some kind of DBI creole -- well, I suppose a lot of other
persistence frameworks are that, pretty much.
13 matches
Mail list logo
