Procedural interface to mysql

[Lars Eighner]

Is there a procedural interface to mysql?

 

[Peter J. Holzer]

Is there a procedural interface to mysql?

What do you mean by "procedural interface"? I assume you know about DBI.
What would a "procedural interface" give you that DBI doesn't?

hp

 

[Lars Eighner]

In our last episode,
the lovely and talented Peter J. Holzer
broadcast on comp.lang.perl.misc:

What do you mean by "procedural interface"? I assume you know about DBI.
Yes.

What would a "procedural interface" give you that DBI doesn't?

No objects. So it would be faster, simpler, more intuitive, more easily
made to do what I want to do instead of what someone thinks I ought to want
to do.

 

[smallpond]

In our last episode,
the lovely and talented Peter J. Holzer
broadcast on comp.lang.perl.misc:


No objects. So it would be faster, simpler, more intuitive, more easily
made to do what I want to do instead of what someone thinks I ought to want
to do.

A method call in perl is a procedural call where the first
argument is passed using strange syntax. The call in
your code:

$dbh = $dsn->connect($user, $password);

is a shorthand way of doing:

$dbh = DBD::mysql::connect($dsn, $user, $password);

The advantage of OO is that $dsn knows what package it
is in, so the checking is done for you. Think of it
that way and it will seem more natural.

--S

 

[Tim Greer]

No objects. So it would be faster, simpler, more intuitive, more
easily made to do what I want to do instead of what someone thinks I
ought to want to do.

Honestly, that would be such a negligible amount of overhead, and it's
pretty intuitive already. If you're worried about speed, you should
consider converting to C and compiling.

 

[Lars Eighner]

Lars Eighner wrote:

Honestly, that would be such a negligible amount of overhead, and it's
pretty intuitive already. If you're worried about speed, you should
consider converting to C and compiling.

I'm gathering, then, that I will have to write my own, because all
database acess in perl is through the OO DBI.

 

[Tim Greer]

I'm gathering, then, that I will have to write my own, because all
database acess in perl is through the OO DBI.

It wouldn't be difficult to write your own without going the OO route.
I just really don't think it's going to have any impact on the speed
(not enough to matter). The current modules that do use OO are very
mature, stable, and do a great deal of things that are big time savers.
However, again. if you want to write your own code, by all means, go
for it.

 

[Peter J. Holzer]

I'm gathering, then, that I will have to write my own, because all
database acess in perl is through the OO DBI.

Back in the perl 4 days, there used to be Oraperl, a procedural (because
perl didn't do OO yet) interface to Oracle. As an interface it still
exists, but these days it just uses DBI in the background. So it won't
be any faster, and it doesn't look simpler to me (well it does, but
that's because it does a lot less - the functionality that Oraperl
provides is just as simple in DBI).

hp

 

[Todd Wade]

I'm gathering, then, that I will have to write my own, because all
database acess in perl is through the OO DBI.

Perhaps show us sample syntax that is going to be "faster, simpler,
more intuitive, and [other things the DBI does that you dont think it
does]?

Todd W.

 

[xhoster]

You could always figure out what the magic package names are and make the
calls procedurally:

$h = get_connection_without_disclosing_password();
print $h;
print $h->selectrow_array("select count(*) from foodata");
print DBI::db::selectrow_array($h,"select count(*) from foodata");
__END__
DBI::db=HASH(0x981a80)
228139983
228139983

You could even make your own wrappers to remember the package names for
you.

Back in the perl 4 days, there used to be Oraperl, a procedural (because
perl didn't do OO yet) interface to Oracle. As an interface it still
exists, but these days it just uses DBI in the background. So it won't
be any faster, and it doesn't look simpler to me (well it does, but
that's because it does a lot less - the functionality that Oraperl
provides is just as simple in DBI).

Sure, but you don't have an irrational hatred of OO like our friend does.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[Eric Pozharski]

In our last episode,
<[email protected]>, the lovely and talented
Peter J. Holzer broadcast on comp.lang.perl.misc: *SKIP*
No objects. So it would be faster, simpler, more intuitive, more
easily made to do what I want to do instead of what someone thinks I
ought to want to do.

Consider this -- Perl's "objects" aren't actually objects in OO sense,
they are "blessed references". Inheritance, methods, constructors etc
are no more than side-effect of blessing *anything* into *package* (not
a class actually).

As soon as you must keep state, you either bless or push responcibility
of knowing what that particular data structure is onto user. In your
case, you must keep state -- you'll end up with hash, I think. And here
either your user must track what that unblessed hash is or Perl will do
that for them.

Next. Don't say that you don't know that these statements are pretty
same: C<$hashref->method($arg);> vs C<method $hashref, $arg;>. The
difference is that in second case there's place for lots of burden.

Next. B<DBI> isn't OO. I see aggregation; I see methods; I don't see
inheritance. Would you like to point at any class that actually
inherits from B<DBI> (OK, I didn't verified that, so I can be
incompetent, as ever)?

And you must know that B<DBI> isn't pure Perl. I think, that any
implementation of the same functionality in pure Perl would be slower.
What functionality would you like to sacrifice for purity? XS on some
API (libmysqlclient in your case)? What you gain in that case? Speed?
Of what? How much time you're going to spend till you'll get working
implementation?

OK. That can be a challenge. I like challenges, they are good cause to
make world better. And I really would like to hear your success story.
But don't complain that you're the only user.

 

[John Bokma]

Would you like to point at any class that actually
inherits from B<DBI>

*points at a class I've written for a customer*

Oh, and I found one for you that's on CPAN:
<http://search.cpan.org/src/TIMB/DBI-1.607/lib/DBI/ProxyServer.pm>


-> @ISA = qw(RPC:lServer DBI);

 

[Charlton Wilbur]

LE> No objects. So it would be faster, simpler, more intuitive,
LE> more easily made to do what I want to do instead of what someone
LE> thinks I ought to want to do.

"Faster" and "simpler" are highly unlikely to both be accomplished at
once. It's a function call either way; you have the overhead of
additional method resolution, but you are spared the morass of PHP-style
mysql_ functions.

"More intuitive" and "more easily made to do what I want to do..." are a
result of your viewpoint rather than anything inherent in object
orientation.

Frankly, you could fairly trivially put a wrapper around DBI calls so that

$sth->prepare (....)

turned into

dbi_prepare ($sth, ....)

but you'd gain nothing except avoiding the visible use of objects, and
the code behind the wrapper would be exactly the same. Would this be
faster, simpler, more intuitive, and easier for you to work with, simply
because you don't *see* that there are objects involved?

If so, the problem is with you, not with objects.

Charlton

 

[Eric Pozharski]

*points at a class I've written for a customer* Oh, and I found one
for you that's on CPAN:
<http://search.cpan.org/src/TIMB/DBI-1.607/lib/DBI/ProxyServer.pm> ->
@ISA = qw(RPC:lServer DBI);

Oh, that hurts. No-one is more lazy than me.