SOAP::Lite versus DBI

[Kirk Strauser]

I'm hoping to build a SOAP server to wrap a FoxPro database.

I built a minimal server:

-----------------------------------------------------------
#!/usr/bin/perl -w

use strict;
use SOAP::Transport::HTTP;
use FoxPro;

my $daemon = SOAP::Transport::HTTP:aemon
-> new (LocalPort => 8080, Reuse => 1)
-> dispatch_to('FoxPro')
;

print "Contact to SOAP server at ", $daemon->url, "\n";
$daemon->handle;
-----------------------------------------------------------

and a package to handle the backend:

-----------------------------------------------------------
#!/usr/bin/perl -w

package FoxPro;

use strict;
use DBI;

# Create a new FoxPro object
sub new
{
my $self = shift;
my $dbpath = shift || '.';
my $class = ref($self) || $self;
bless {'_dbpath' => $dbpath} => $class;
}

# Execute a query on a named table and return a handle to the result.
sub execute
{
my $self = shift;
my $query = shift;
my $limit = shift || 10;
my $dbh = DBI->connect("DBI:XBase:$self->{'_dbpath'}") or die $DBI::errstr;
my $sth = $dbh->prepare($query);
$sth->execute();
return $sth;
}
-----------------------------------------------------------

Now, I can use the FoxPro module locally, but when I run the little server
and try to pull results from it, I get errors like:

dbih_getcom handle DBI::st=HASH(0x86848dc) is not a DBI handle (has no magic)

I've Googled about, and it seems that other people have had similar
problems, but I've never found an answer to their questions. Is there
some problem passing around statement handles via SOAP::Lite that doesn't
exists when calling the modules locally?

 

[Bryan Castillo]

I'm hoping to build a SOAP server to wrap a FoxPro database.

I built a minimal server:

-----------------------------------------------------------
#!/usr/bin/perl -w

use strict;
use SOAP::Transport::HTTP;
use FoxPro;

my $daemon = SOAP::Transport::HTTP:aemon
-> new (LocalPort => 8080, Reuse => 1)
-> dispatch_to('FoxPro')
;

print "Contact to SOAP server at ", $daemon->url, "\n";
$daemon->handle;
-----------------------------------------------------------

and a package to handle the backend:

-----------------------------------------------------------
#!/usr/bin/perl -w

package FoxPro;

use strict;
use DBI;

# Create a new FoxPro object
sub new
{
my $self = shift;
my $dbpath = shift || '.';
my $class = ref($self) || $self;
bless {'_dbpath' => $dbpath} => $class;
}

# Execute a query on a named table and return a handle to the result.
sub execute
{
my $self = shift;
my $query = shift;
my $limit = shift || 10;
my $dbh = DBI->connect("DBI:XBase:$self->{'_dbpath'}") or die $DBI::errstr;
my $sth = $dbh->prepare($query);
$sth->execute();
return $sth;
}
-----------------------------------------------------------

Now, I can use the FoxPro module locally, but when I run the little server
and try to pull results from it, I get errors like:

dbih_getcom handle DBI::st=HASH(0x86848dc) is not a DBI handle (has no magic)

I've Googled about, and it seems that other people have had similar
problems, but I've never found an answer to their questions. Is there
some problem passing around statement handles via SOAP::Lite that doesn't
exists when calling the modules locally?

I don't know for sure but.....

I imagine that a statement handle object is a complex object that
probably has some C code behind it. Perhaps it has a C struct stashed
away in the implementation with pointers to various places in memory.
In which any case, the object wouldn't serialize very well over a
network connection. There are some things that just don't serialize
very well. You might want to try keeping the object stored in a hash
within the server code and return the key through the soap calls.
This key would be the first argument of all your methods and you would
use that to look up the real object and call the methods on that.
Very similar to the idea of a session.

 

[Kirk Strauser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't know for sure but.....

I imagine that a statement handle object is a complex object that probably
has some C code behind it. Perhaps it has a C struct stashed away in the
implementation with pointers to various places in memory. In which any
case, the object wouldn't serialize very well over a network connection.

I was kind of suspecting the same thing. I'd read something about
SOAP::Lite returning "stub" objects that were basically pointers to the real
object residing on the server, but couldn't get find enough information to
convince me that was accurate.

You might want to try keeping the object stored in a hash within the
server code and return the key through the soap calls.

That was going to be my next effort.
- --
Kirk Strauser
The Strauser Group
Open. Solutions. Simple.
http://www.strausergroup.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/u3YO5sRg+Y0CpvERAvMnAJ9bKYQ4LtCdN9Sp3OuU6HnrbPjPQgCghnYR
q7Ib0rET4vWIJ6Uz8Lo8c9s=
=UsrW
-----END PGP SIGNATURE-----