pas-dev

[mortis@voicenet.com: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config]

[Kyle R . B. <mo...@vo...>]

----- Forwarded message from "Kyle R . Burton" <mo...@vo...> -----

Date: Fri, 17 May 2002 12:46:12 -0400
From: "Kyle R . Burton" <mo...@vo...>
To: Justin Bedard <ju...@le...>
Subject: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config
Reply-To: "Kyle R . Burton" <mo...@vo...>
X-Mailer: Mutt 095 us
In-Reply-To: <3CE...@le...>; from Justin Bedard on Fri, May 17, 2002 at 12:34:13PM -0400

> +1 for PSP templates for DB record obj gen.
> +1 for log4j (it's big pimpin'!)
> +1 for TestCase
> +1 for Error.pm
> +1 for makeGetSet() altho in a web application, we really haven't seen
> the performance hit of gss() but it does clean up some stuff.

Every little bit means more latency on the site, and less scalability.  
Besides, it's an infrastructure issue, _and_ it's effectivly bettern than
free, you get benefit (clartiy, maintainability, speed) with less cost 
(less lines of code to write).

> +1 for improving security

That's the input filter for script/embed tags just to make it clear.

I'll go and update the status on these as accepted but needs implementing.

> +1 for Jason (so he can vote twice this one time)

No, no developer get's more than 1 vote. (I know I'll come to regret this
at some point, but we're a community not a tyranny).

> +1 for some kind of Base SQL object and have PostgreSQL & MySQL derive from it.

Do you have any ideas for how to do this?  If you do, write up a proposal
on how to do it.

> +1 to just have a PostgreSQL plugin.
> +1 for type checking.  i guess we can have different makeGetSets... 
> makeGetSetString(), makeGetSetInt(), makeGetSetFloat(), etc.

Hrm...that could be a good thing.  Though for SQL purposes, we also
want to track precision -- INTEGER(2) vs NUMBER(14).  That of course
raises yet other issues with database differences -- MySQL, Oracle,
and PostgreSQL all uses different types for their columns....should we
just leave these validation routines up to the PSP templates?  Or a parent
object written for just such a purpose?  Actualy, that's not a bad idea:

 Org::Bgw::Pas::Db::RecBase
   |
   +--Org::Bgw::Pas::Db::MySQLRec
   |
   +--Org::Bgw::Pas::Db::PgRec

Could RecBase do most of the abstracted stuff?  With the derived
ones deferred to for the actual implementations?  How would that work
for these type validation/checking issues?

> -1 for Kyle for not letting both of Jason's brain cells vote.
> 
> did i cover them all?

How about _writing_ either documentation or, better yet, code 
instead of just voting?  eh?

:)

Kyle

-- 

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

----- End forwarded message -----

-- 

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

Re: [mortis@voicenet.com: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config]

[Justin B. <ju...@le...>]

-1 for not being able to hit REPLY ALL!  :P

Kyle R . Burton wrote:
> ----- Forwarded message from "Kyle R . Burton" <mo...@vo...> -----
> 
> Date: Fri, 17 May 2002 12:46:12 -0400
> From: "Kyle R . Burton" <mo...@vo...>
> To: Justin Bedard <ju...@le...>
> Subject: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config
> Reply-To: "Kyle R . Burton" <mo...@vo...>
> X-Mailer: Mutt 095 us
> In-Reply-To: <3CE...@le...>; from Justin Bedard on Fri, May 17, 2002 at 12:34:13PM -0400
> 
> 
>>+1 for PSP templates for DB record obj gen.
>>+1 for log4j (it's big pimpin'!)
>>+1 for TestCase
>>+1 for Error.pm
>>+1 for makeGetSet() altho in a web application, we really haven't seen
>>the performance hit of gss() but it does clean up some stuff.
> 
> Every little bit means more latency on the site, and less scalability.  
> Besides, it's an infrastructure issue, _and_ it's effectivly bettern than
> free, you get benefit (clartiy, maintainability, speed) with less cost 
> (less lines of code to write).

I agreed with the clarity.  Most of the time clarity can equal maintainability. 
  I already know it means speed.  Previous job we didn't run into the speed 
issue.  Current job we did but we're using gss() outside of PAS.

>>+1 for improving security
> 
> That's the input filter for script/embed tags just to make it clear.
> 
> I'll go and update the status on these as accepted but needs implementing.
 >
>>+1 for Jason (so he can vote twice this one time)
> 
> No, no developer get's more than 1 vote. (I know I'll come to regret this
> at some point, but we're a community not a tyranny).

But a dictatorship on how we vote is allowed?!?!  :P

>>+1 for some kind of Base SQL object and have PostgreSQL & MySQL derive from it.
> 
> Do you have any ideas for how to do this?  If you do, write up a proposal
> on how to do it.

I'd have to look at the code.  It's been too long.

>>+1 to just have a PostgreSQL plugin.
>>+1 for type checking.  i guess we can have different makeGetSets... 
>>makeGetSetString(), makeGetSetInt(), makeGetSetFloat(), etc.
> 
> Hrm...that could be a good thing.  Though for SQL purposes, we also
> want to track precision -- INTEGER(2) vs NUMBER(14).  That of course

Well, you could end up passing it an integer during construction so that it will 
also check length if that integer is defined.  You can't do:

makeGetSet(qw( foo bar kyle dictator ))

So you sorta go back to some of the maintenance issues of gss() but not nearly 
as bad.  Just thinking out loud.  Might be a better way to get length check in 
there.

> raises yet other issues with database differences -- MySQL, Oracle,
> and PostgreSQL all uses different types for their columns....should we
> just leave these validation routines up to the PSP templates?  Or a parent
> object written for just such a purpose?  Actualy, that's not a bad idea:
> 
>  Org::Bgw::Pas::Db::RecBase
>    |
>    +--Org::Bgw::Pas::Db::MySQLRec
>    |
>    +--Org::Bgw::Pas::Db::PgRec
> 
> Could RecBase do most of the abstracted stuff?  With the derived
> ones deferred to for the actual implementations?  How would that work
> for these type validation/checking issues?

Possibly.  Still need to look into how to implement length checking.

>>-1 for Kyle for not letting both of Jason's brain cells vote.
>>
>>did i cover them all?
> 
> How about _writing_ either documentation or, better yet, code 
> instead of just voting?  eh?

I'm a slow reader.  I'm just having problems keeping up with these emails.  :P 
How about I finish the address matching stuff first for my J-O-B.  ;)

Justin

Re: [mortis@voicenet.com: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config]

[Justin B. <ju...@le...>]

>>+1 for some kind of Base SQL object and have PostgreSQL & MySQL derive from it.
> 
> 
> Do you have any ideas for how to do this?  If you do, write up a proposal
> on how to do it.

First off, in the config file, remove all references to mysql in the pas.session 
name space.  ;)

Looking at Org::Bgw::Pas::Session::MySQL::Factory:

- All the constants can go in the parent object.

- load_session_rec() should be able to go in the parent without having to be 
overridden.  Am I correct or making too much of an assumption?  Just because I'm 
not sure of the blob issues between Mysql, PostgreSQL, Oracle, etc.

- store_session_rec() goes in the parent.

- update_session_rec() becomes an abstract method in the parent.  It must be 
ovewritten.

- insert_session_rec() will follow update_session_rec() lead.

- update_atime_for_session_rec() goes in the parent(?).

- db_hostname(), db_dbname(), db_table(), get_username(), get_password() all to 
the parent class.

- get_dsn() goes to the parent with one modification.  We add an abstract method 
namded db_driver() to the parent.  db_driver() will return a constant value of 
"mysql" or "Pg" or etc. in the child depending on the class.  Unless the dns 
syntax is that different from DB to DB.  I guess it also depends on how 
someone's configured their DB connections too.  Either way, it's easy enough to 
abstract to the children.  And if we get the generic way to work, just put a 
note in the docs of what to look for to override.

Justin

Re: [mortis@voicenet.com: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config]

[Kyle R . B. <mo...@vo...>]

Excellent!  Would you mind writing that up as a proposal and checking it
in to the archive?

> >>+1 for some kind of Base SQL object and have PostgreSQL & MySQL derive from it.
> > 
> > 
> > Do you have any ideas for how to do this?  If you do, write up a proposal
> > on how to do it.
> 
> First off, in the config file, remove all references to mysql in the pas.session 
> name space.  ;)
> 
> Looking at Org::Bgw::Pas::Session::MySQL::Factory:
> 
> - All the constants can go in the parent object.
> 
> - load_session_rec() should be able to go in the parent without having to be 
> overridden.  Am I correct or making too much of an assumption?  Just because I'm 
> not sure of the blob issues between Mysql, PostgreSQL, Oracle, etc.
> 
> - store_session_rec() goes in the parent.
> 
> - update_session_rec() becomes an abstract method in the parent.  It must be 
> ovewritten.
> 
> - insert_session_rec() will follow update_session_rec() lead.
> 
> - update_atime_for_session_rec() goes in the parent(?).
> 
> - db_hostname(), db_dbname(), db_table(), get_username(), get_password() all to 
> the parent class.
> 
> - get_dsn() goes to the parent with one modification.  We add an abstract method 
> namded db_driver() to the parent.  db_driver() will return a constant value of 
> "mysql" or "Pg" or etc. in the child depending on the class.  Unless the dns 
> syntax is that different from DB to DB.  I guess it also depends on how 
> someone's configured their DB connections too.  Either way, it's easy enough to 
> abstract to the children.  And if we get the generic way to work, just put a 
> note in the docs of what to look for to override.
> 
> Justin
> 

-- 

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

[Pas-dev] generic session DB factory

[Justin B. <ju...@le...>]

docs/proposals/genericSessionDbFactory

justin

Kyle R . Burton wrote:
> Excellent!  Would you mind writing that up as a proposal and checking it
> in to the archive?