[geeklog-devel] Is this rocking the boat?

[Tony Bibbs]

Well, as far as other DB connections go, that is up to the coder, 
obviously.  GL2 should only worry about talking to the GL2 database so 
if you want to access another database you should, without much hassle, 
be able to open connections using the Creole DB layer that Propel uses:

http://creole.phpdb.org/wiki/

Obviously you can still do your own with PEAR::DB or raw MySQL in your 
code.  The DAO layer simply provides a slick way to prevent the 
developer from issuing raw SQL in the code...sometimes that can't be 
avoided and I'm sure there is probably way to issue raw SQL in unique 
scenarios (I need to verify that).

--Tony

Blaine Lang wrote:

>It does look interesting and like many new libraries or models, it may be
>able to improve code readability, reduce code size, and improve
>re-useability but I do wonder if
> 1) There are any SQL usage restrictions or more complex SQL queries that
>will not work.
> 2) Will you still be able to use another DB access method and direct mysql_
>calls using PHP
> 3) Making GL2 too complex to understand for developers will effect it's
>support
>
>I have had reason on several occasions to need to access another mysql
>database when doing application integration. I just used the direct php
>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x
>does not support this. We should consider this need in GL2
>
>Blaine
>----- Original Message ----- 
>From: "Vincent Furia" <vfuria at gmail.com>
>To: <geeklog-devel at lists.geeklog.net>
>Sent: Saturday, July 31, 2004 11:17 PM
>Subject: Re: [geeklog-devel] Is this rocking the boat?
>
>
>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
>>
>>    
>>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>  
>