[geeklog-devel] Is this rocking the boat?

[Vincent Furia]

I haven't had enough time to read up on this extensively, but it looks
promising.  We just have to make sure that it fulfills all our needs
completely and won't cause any problems down the road.  Also, we have
to be able to support it on the off chance that the current developers
drop the project.

My one worry is possible performance penalties.  I think we should
check how much overhead Propel requires.

Most importantly:  I want to see GL2 get moving really soon. So a
decision on this has to happen soon.  Can we get enough research done
on this topic that we're not causing more delays?

I'll spend some more time reading the Propel docs. If nothing else the
idea sounds pretty interesting.

-Vinny

On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> Ok, I think I sent this link here, but the more I read what I see, the
> more I like it.  Please take some time to read about Propel:
> 
> http://propel.phpdb.org
> 
> And read the user guide:
> 
> http://propel.phpdb.org/docs/user_guide/
> 
> The long and short of it is this.  We could implement Data Acces Objects
> that our code uses to interact with the database.  DAO is a good idea no
> matter what DB abstraction layer we use and regardless if we use a tool
> like Propel.  Essentially it hides the data access specifics from the
> developers.  Instead developers will call simple methods on the data
> access objects and let the DAO layer do the grunt work.
> 
> We could essentially use DAO to wrap the use of Propel for data acess.
> 
> That said there are some pros and cons:
> 
> Pros:
> 1) Clean API, developers no longer have to write SQL except in really
> rare instances.
> 2) Object oriented...right in line with GL2
> 3) Database changes are easier, now developers don't have to find all
> SQL effected by a database change.  We simply change things at the
> Propel level (wrapped by DAO), modify our HTML templates and we are off
> to the race.
> 
> Cons:
> 1) It is conceptionally more complicated.  Requires some ramp up.
> 2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even
> if you wanted to).
> 3) It's in Beta.
> 
> I think this tool could really save a ton of time.  Please give this a
> gander and try using it against a very simply table and let me know your
> thoughts.
> 
> --Tony
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>