[geeklog-devel] GL2 DataAccess Class

[Tony Bibbs]

Vinny, finally getting back to addressing some issues. You are right 
here. However, 95% of the inserts, updates and deletes should come 
through the use of the domain objects themselves, right? For the 
remaining 5%, I think they should just use raw SQL in the named query file.

So to be clear you'd use the PropelDAO::save to do the inserts and 
updates and the PropelDAO::delete to delete an object.

Correct me if I am missing something.

--Tony

Vincent Furia wrote:

>I guess I should have been more specific...
>
>There is no way to use criteria to do UPDATEs or DELETEs (criteria
>with INSERTs doesn't make much sense).
>
>It is not clear if what behavior specifying the SQL for UDPATEs,
>DELETEs and INSERTs will be.  From reading the code it looks like the
>SQL will be executed, I'm just not sure if the program will stop with
>an error afterwards or throw an exception or just return an empty
>result set.
>
>I haven't tested the DAO code under these conditions, but it looks
>like something that needs be corrected.
>
>-Vinny
>
>
>On Mon, 17 Jan 2005 11:41:21 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
>  
>
>>You sure?  It's an easy fix to get around that...but seems the
>>updates/deletes should work.
>>
>>--Tony
>>
>>Vincent Furia wrote:
>>
>>    
>>
>>>Tony,
>>>
>>>Another issue with the DAO class is that it seems catered to providing
>>>support only for SELECT's.  It won't work for doing INSERT's,
>>>UPDATE's, or DELETE's (etc...).
>>>
>>>-Vinny
>>>
>>>
>>>On Mon, 17 Jan 2005 09:39:04 -0500, Vincent Furia <vfuria at gmail.com> wrote:
>>>
>>>
>>>      
>>>
>>>>Tony,
>>>>
>>>>Caching between page calls would be great.  But even having a static
>>>>variable or something similar to persist between calls to the "find"
>>>>method would be a good start (and probably sufficient for most sites).
>>>>
>>>>-Vinny
>>>>
>>>>
>>>>On Mon, 17 Jan 2005 08:32:53 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>You mean cache it to memory or to a file.  I'd love to cache it to
>>>>>memory but, afaik, it would require php's shared memory which isn't
>>>>>enabled by default.
>>>>>
>>>>>I s'pose if the xml parsing itself if that bad, would could cache a
>>>>>php-friendly data structure to a file.
>>>>>
>>>>>I'm open to this.  I just learned how to profile PHP applications this
>>>>>past week so finding poor performing code shouldn't be a problem.
>>>>>
>>>>>--Tony
>>>>>
>>>>>Vincent Furia wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Tony,
>>>>>>
>>>>>>Just looking through the DAO to understand everything it is doing
>>>>>>better.  I noticed that the "find" method (and the other methods)
>>>>>>reloads the named queries from the xml file on every call.  We should
>>>>>>look for a way to work around this (i.e. somehow cache the DOMXPath
>>>>>>object) so as not to suffer huge penalties for parsing the XML file on
>>>>>>every DB call.
>>>>>>
>>>>>>-Vinny
>>>>>>_______________________________________________
>>>>>>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
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>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
>  
>