Objects from database entry 
Author Message
 Objects from database entry

Hi,

I developed a module for my personal use which lets you
query a DBI database and return the result as object/s.
If the table has a field called name you can do something
like this: $obj->name($newName)
As soon as you tell it or just before destruction (with
a warning and a ping to the DBI object) $obj syncs itself
with the database.

The result is that you never have to worry about writing
SQL statements or any other database issue. You just treat
the database entries as normal Perl objects, and thats all
you have to worry about.

I know there are full blown objects-to-relational-mapper
and object-persistency modules on CPAN, but I didnt find
any module which was as simple as mine. It may be not usable
for  hard stuff, but it's really cool if you want to do quick
development. I use it for website development every day.

Maybe I just overlooked something at CPAN and there is a
module that does exactly what mine does. But if not, it
might be interesting to some people. If that's the case or
if you or if you have some hints and suggestions, please
reply to this post, so I can decide whether it's worth to
make the implementation ready for CPAN.

Bye,
->malte



Tue, 08 Jul 2003 22:22:25 GMT  
 Objects from database entry

Quote:

> Hi,

> I developed a module for my personal use which lets you
> query a DBI database and return the result as object/s.

sounds like BingoX::Carbon
http://theoryx5.uwinnipeg.ca/CPAN/data/BingoX/BingoX/Carbon.html

Quote:
> If the table has a field called name you can do something
> like this: $obj->name($newName)
> As soon as you tell it or just before destruction (with
> a warning and a ping to the DBI object) $obj syncs itself
> with the database.

> The result is that you never have to worry about writing
> SQL statements or any other database issue. You just treat
> the database entries as normal Perl objects, and thats all
> you have to worry about.

What is the query returns a large number of rows? Can you retrieve the
rows incrementally?

Quote:
> I know there are full blown objects-to-relational-mapper
> and object-persistency modules on CPAN, but I didnt find
> any module which was as simple as mine. It may be not usable
> for  hard stuff, but it's really cool if you want to do quick
> development. I use it for website development every day.

DBIx::Recordset and TableMap are two more which come to mind.


Thu, 10 Jul 2003 03:53:32 GMT  
 Objects from database entry
Terrence Brannon schrieb:

Quote:
> sounds like BingoX::Carbon
> http://theoryx5.uwinnipeg.ca/CPAN/data/BingoX/BingoX/Carbon.html

That one does a lot more. However, it uses transactions, so you
cant use it mit MySQL

Quote:
> > The result is that you never have to worry about writing
> > SQL statements or any other database issue. You just treat
> > the database entries as normal Perl objects, and thats all
> > you have to worry about.

> What is the query returns a large number of rows? Can you retrieve the
> rows incrementally?

Would be a nice feature, and should be easy to implement. I don't have
that in yet, because I, personally, most of the time deal with querys
returning a single row.

Quote:
> > I know there are full blown objects-to-relational-mapper
> > and object-persistency modules on CPAN, but I didnt find
> > any module which was as simple as mine. It may be not usable
> > for  hard stuff, but it's really cool if you want to do quick
> > development. I use it for website development every day.

> DBIx::Recordset and TableMap are two more which come to mind.

I didnt find TableMap. DBIx::Recordset is a nice module. What it lacks
is a really simple interface, or is it just me who thinks that
$obj->birthday is a lot cleaner than $obj->field("birthday")?

Thanks for answering,
->malte



Thu, 10 Jul 2003 21:30:51 GMT  
 Objects from database entry

Quote:

> > > The result is that you never have to worry about writing
> > > SQL statements or any other database issue. You just treat
> > > the database entries as normal Perl objects, and thats all
> > > you have to worry about.

> > What is the query returns a large number of rows? Can you retrieve the
> > rows incrementally?

> Would be a nice feature, and should be easy to implement. I don't have
> that in yet, because I, personally, most of the time deal with querys
> returning a single row.

What the world really needs (or rather, what the Perl world really
needs) is a simple module that does all the basic DBI-style stuff for
you, and, crucially, does it simply and effectively. For instance, if
you're fetching a large number of rows from a database, you a) don't
want to read them all into memory, you want to read them line by line;
and b) you want to do things as fast as possible.

This conflicts with the very Perlish ideal of fetching database rows as
an array of hashrefs. I for one would ask very serious questions of
someone who fetched database information as an array, just because
they're writing code that *relies* on the order of fields in a database
table, which is an absolute pain when you have to modify the table.

Assuming you're going to be fetching multiple rows as hashrefs, what you
want to do is something like the following (this may well be mySQL-ish;
if so, apologies):
 # Assume $sth is a DBI statement handle
 $sth->execute;
 my $fields=$sth->{NAME};
 my %values;

 while ($sth->fetchrow_arrayref) {
    # %values contains the row values
 }
 $sth->finish;

This is *significantly* faster than fetchrow_hashref, and hardly slower
at all than a vanilla fetchrow_arrayref.

Of course, you can't really expect everyone to duplicate this rather
hairy code (which also confuses the Emacs Perl parser, annoyingly) -
which is why you put it in a separate module.

I have my own very simple Perl DBI abstraction module that I use internally;
I've put it up at http://www.illuminated.co.uk/perl/Database.tar.gz
if anyone wants to take a look. Having had a look at all the DBIx::*
modules I don't really think it's worth uploading to CPAN, but I'm
perfectly happy to contribute code from it to other modules.

[...]

Quote:
> I didnt find TableMap. DBIx::Recordset is a nice module. What it lacks
> is a really simple interface, or is it just me who thinks that
> $obj->birthday is a lot cleaner than $obj->field("birthday")?

Only if you can hard-code the field name into the code. Yes, saying
something like
 &charge_creditcard($obj->creditcard, $obj->expiry, $obj->issue)
is nicer than saying
 &charge_creditcard(map { $obj->field($_) } qw(creditcard expiry issue)}

But if you have, say,
 &grabfields(qw(foo bar baz));
 # ...
 sub grabfields {
    # Assume you have $obj around somehow

 }
then you'd far prefer to say
 sub grabfields {

 }

The solution, of course, is to provide both interfaces. (One thing I
like about Damian Conway's stuff: if you don't like the default way of
doing things, he gives you two or three other ways of doing things.)

Sam
--
Home page: http://www.illuminated.co.uk/
INWO Homebrew: http://www.illuminated.co.uk/inwo/
"The worst moment for an atheist is when he is really thankful and has
nobody to thank" - Dante Gabriel Rossetti



Fri, 11 Jul 2003 10:14:21 GMT  
 Objects from database entry

Quote:


> > > > The result is that you never have to worry about writing
> > > > SQL statements or any other database issue. You just treat
> > > > the database entries as normal Perl objects, and thats all
> > > > you have to worry about.

> > > What is the query returns a large number of rows? Can you retrieve the
> > > rows incrementally?

> > Would be a nice feature, and should be easy to implement. I don't have
> > that in yet, because I, personally, most of the time deal with querys
> > returning a single row.

> What the world really needs (or rather, what the Perl world really
> needs) is a simple module that does all the basic DBI-style stuff for
> you, and, crucially, does it simply and effectively. For instance, if
> you're fetching a large number of rows from a database, you a) don't
> want to read them all into memory, you want to read them line by line;
> and b) you want to do things as fast as possible.

> This conflicts with the very Perlish ideal of fetching database rows as
> an array of hashrefs. I for one would ask very serious questions of
> someone who fetched database information as an array, just because
> they're writing code that *relies* on the order of fields in a database
> table, which is an absolute pain when you have to modify the table.

That's just the point of my articles on DBIx::Recordset. You can read
them at www.SAHASH.org

- Show quoted text -

Quote:

> Assuming you're going to be fetching multiple rows as hashrefs, what you
> want to do is something like the following (this may well be mySQL-ish;
> if so, apologies):
>  # Assume $sth is a DBI statement handle
>  $sth->execute;
>  my $fields=$sth->{NAME};
>  my %values;

>  while ($sth->fetchrow_arrayref) {
>     # %values contains the row values
>  }
>  $sth->finish;

> This is *significantly* faster than fetchrow_hashref, and hardly slower
> at all than a vanilla fetchrow_arrayref.

> Of course, you can't really expect everyone to duplicate this rather
> hairy code (which also confuses the Emacs Perl parser, annoyingly) -
> which is why you put it in a separate module.

did you type M-x cperl-mode

perl-mode is less powerful than cperl-mode

Quote:

> I have my own very simple Perl DBI abstraction module that I use internally;
> I've put it up at http://www.illuminated.co.uk/perl/Database.tar.gz
> if anyone wants to take a look. Having had a look at all the DBIx::*
> modules I don't really think it's worth uploading to CPAN, but I'm
> perfectly happy to contribute code from it to other modules.

> [...]
> > I didnt find TableMap. DBIx::Recordset is a nice module. What it lacks

http://theoryx5.uwinnipeg.ca/CPAN/data/TableMap/TableMap.html

Quote:
> > is a really simple interface, or is it just me who thinks that
> > $obj->birthday is a lot cleaner than $obj->field("birthday")?

> Only if you can hard-code the field name into the code. Yes, saying
> something like
>  &charge_creditcard($obj->creditcard, $obj->expiry, $obj->issue)
> is nicer than saying
>  &charge_creditcard(map { $obj->field($_) } qw(creditcard expiry issue)}

Hmm, good point.

Quote:

> But if you have, say,
>  &grabfields(qw(foo bar baz));
>  # ...
>  sub grabfields {
>     # Assume you have $obj around somehow

>  }
> then you'd far prefer to say
>  sub grabfields {

>  }

--
Terrence Brannon
Carter's Compass...
    I know I'm on the right track when by deleting code I'm adding
    functionality.


Fri, 11 Jul 2003 22:22:55 GMT  
 Objects from database entry
Sam Kington schrieb:

Quote:
> But if you have, say,
>  &grabfields(qw(foo bar baz));
>  # ...
>  sub grabfields {
>     # Assume you have $obj around somehow

>  }
> then you'd far prefer to say
>  sub grabfields {

>  }

> The solution, of course, is to provide both interfaces. (One thing I
> like about Damian Conway's stuff: if you don't like the default way of
> doing things, he gives you two or three other ways of doing things.)

Yeah, I know I always think in terms of websites where you merely display
data and you always know where something goes, rather than doing mass-
processing. But anyway, having the traditional interface, shouldnt be
a problem. Of course all that happens when you call $obj->name()

sub AUTOLOAD {
        my $self = shift;
        # do processing on $AUTOLOAD

Quote:
}

As a conclusion one could still call field directly if that is appropriate.

->malte



Fri, 11 Jul 2003 23:46:10 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. assigning to subroutine entry in an object

2. Nonmember submission: entry object problem

3. Data Entry / Database routines for perl

4. Realy strange database entry problem

5. Problem with duplicate entries in database

6. Sorting Database Entries

7. Database entry ID - how to?

8. Deleting entries in a database--help?

9. OraPerl - oracle database objects ?

10. Perl object database Pogo0.06 released

11. Object->Database Framework

12. calling ole objects from the database to the html page using perl

 

 
Powered by phpBB® Forum Software