pas-dev Mailing List for Perl Application Server (Page 17)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> Sounds reasonable. I often get the feeling we're following java at this
> point. I suppose we are. Still, its a good idea. I can see it being
> useful.

Yea and no.  We're modeling the good aspects of JSP and the servelt model
as those aspects translate and work well in the Perl/mod_perl arena.

The log4j package is not Java, it is just a really good logging package that
happens to have been first written in Java.  Now it's available for Perl,
and it's good, so I say we use it.

That's 2 +1s, anyone else have an opinion?

> > Second proposal: Exception handling
>
> It didnt silently fail, it was in pas.log, just not in the browser. But
> yes. Why reinvent the wheel? Error.pm does indeed have some nice
> to-haves. Leverage CPAN and note it in the INSTALL.

That's 2 +1s, anyone else have an opinion?

> > Third proposal: get rid of _gss()/_get_set_scalar()
> 
> I agree for different reasons. I feel generic get/set functions are
> error prone. Except in the most basic situations they're probably not
> what you want. If its just a string to display, remember it. 

What errors?  Their purpose is to keep you from writing the ever present
standard get/set functions.  That's all - if you need more functionality,
then don't use it, write the get/set yourself and add in the desired
behavior.  Just because it's there doesn't mean you have to use it, it's
optional so you don't have to use it if it's not appropriate.

> The context of this will determine if I like it or not. 

The only difference between makeGetSetMethods() and _gss() is that
_gss is slower, and you have to write more code, which opens up possibilities
for errors.  That's it.

I know I've doen this before:

  sub foo {shift->_gss('foo');}

and wasted time debugging it, when it should have been:

  sub foo {shift->_gss('foo',@_);}

makeGetSet is better for these kinds of programmer errors.  It is also
faster because there is 1 level of function call involved, not two.  It's
also faster, because you're not shifting @_ to call your parent's _gss()
method.

The only faster thing I know of (besides going back to direct hash access)
is to use pseudo hashes, and I'm not going to suggest that for a few 
reasons - it's documented as experimental, and in Larry's most recent 
state of the Onion, he talks about getting rid of them.

> They also dont catch errors. And thats a big issue with me right now.
> For blobby unstructured data, rock on. But for db stuff, this causes
> issues further down the road. 

You talk about this more below, so I'll comment on it there.

> It also raises the issue of backwards compatibility. Will this cause
> code to break? If its transparent to 'old style' stuff, fine. If not, is
> this a new branch/release major version/whatever? Just asking. They're
> good ideas.

Most of it will not.  Some of the codebase is already using makeGetSetMethods.
The change to Exception should be drastic - we should gut the codebase of
all instances of $self->throw().  The logging change should also be drastic
in the same way.  

> I think I'm seeing the issues with DB abstraction so I'm doing a first
> round of 'just make it work' coding. 
> 
> I do have a fourth proposal.
> 
> four: Modify object generator to gen smarter objects.

I personaly like this.  On a project Justin and I just did, and in 
some conversations I had with Andy, we want to generate the proper
SQL staemetns for SELECT,INSERT,UPDATE and DELETE.  That way they
can deferr to a parent object for these operatsions -- the generated
record objects will be smart enough to know how to perform these operations
on themselves.  For the project Justin and I worked on, we only wrote
sql statements for reporting purposes.  Of the few hundred sql statemetns
we would have had to write for the 30 or so database tables, they all
got handled implicitly by the code in the generated objects.  That saved
us no end of time.  Of course it's not necessarily the most optimized
SQL code, but we optmized afterwards when we saw hotspots in the 
application, which ended up being about 2 places.

> I think we can make db records be smart enough that when I call a get
> set with bad data, the object catches it and yells.
> 
> Thus, if an object is generated and has a get/set for a number 2 column,
> and  call $obj->foo('string'), it shouldn't like it. My argument for
> doing this is its easier to do when generating an object than it is when
> trying to store an object. Its too error prone. And getting exceptions
> on insert doesnt always tell me _which_ value was too large for a
> column. The side effect of this is that we're probably going to have to
> subclass objectgenerator for every database we support to deal with
> their different personalitys. Since we currently only support MySQL,
> this isnt a huge amount of work. However, going forward, the question of
> access to every possible backend becomes an issue.

I like the idea of adding in type checking or validation.  We could
either make that a switch on the generator, or a run-time swtich so
you could use it in development, and turn it off for production for
speed/performance reasons.

> What do you think? This lack of data checking in generated objects is
> making me seriously rethink their merits. Sure it takes longer, but I
> can write an object by hand that will not accept bad data. I'd rather
> spend the time up front writing the object, than debugging on insert
> errors. 

I have a new proposal for the generator.  The current appraoch sucks.
I don't think we need to sub-class the generator, we need to throw it away.  
As It is currently written it is a bad approach (too much maintenence).

I propose that we do what Justin and I did for the last project at HMS:
use PSP to generate the objects.  It's _soo_ much easier.  We write
a driver program:

  dbRecGenerator.pl --dbiDsn="dsnString" --dbUser=user --dbPass=pass \
     --dbTable=TABLE_NAME --genClassName=Some::Class::RecName \
     --pspTemplate=recGen.psp

The driver program connects to the database, and puts togeather a data
structure (or better yet, an object) that has all of the data about the
table.  Then the PSP looks like this:

  <%
    my $tableInfo = $self->query()->param('tableInfo');
    my $packageName = $self->query()->param('packageName');
  %>package <%= $packageName %>;
  use strict;
  use warnings;
  <%
    foreach my $use ( @someListOfObjectsToUse ) {
  %>
  use <%= $use %>;
  <%
    }
  %>
  our @ISA = qw( <%= @ourParentList %> );

  <% foreach my $colInfo ( $tableInfo->columns() ) { %>
  sub <%= $colInfo->functionName() %>
  {
    my($self) = @_;
    if( @_ > 2 ) { # a set
      $self->validate<%= $colInfo->functionName() %>($_[1]);
      return $self->setVal(x,y,z); # something like that
    }

    # put get code here
  }

  sub validate<%= $colInfo->functionName() %>
  {
    my($self,$val) = @_;
    # do your validation based on the col type and precision here...
  }
  <% } %>

  sub recInsertSql
  {
    # return sql for a basic insert
  }
  # also do a select, update, and delete...

  1;

Does this make sense?  Then you can just substitute out the particular
psp template that generates the recod objects in the way you like it to.

The templates will be infinitly easier to create and maintain than the
current borked generator design.

Comments?

Kyle

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

2002	Jan	Feb (6)	Mar (19)	Apr (3)	May (147)	Jun (6)	Jul (4)	Aug (12)	Sep (1)	Oct (12)	Nov (23)	Dec (3)
2003	Jan (4)	Feb (12)	Mar (13)	Apr (16)	May (28)	Jun (9)	Jul (1)	Aug (2)	Sep	Oct	Nov (84)	Dec (25)
2004	Jan (5)	Feb	Mar	Apr	May	Jun	Jul	Aug (13)	Sep	Oct	Nov	Dec
2005	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug (5)	Sep (5)	Oct	Nov	Dec

pas-dev Mailing List for Perl Application Server (Page 17)

pas-dev — Development mailing list.