[Fwd: Re: [geeklog-devel] GL2 DataAccess Class]

[Tony Bibbs]

Forgot to include the list.

--Tony

-------- Original Message --------
Subject: 	Re: [geeklog-devel] GL2 DataAccess Class
Date: 	Fri, 28 Jan 2005 15:46:53 -0600
From: 	Tony Bibbs <tony at tonybibbs.com>
To: 	vmf at abtech.org
References: 	<8319e2d60501162044335efb64 at mail.gmail.com> 
<41EBCC95.7080203 at tonybibbs.com> 
<8319e2d605011706391e0c02d7 at mail.gmail.com> 
<8319e2d6050117070717a15298 at mail.gmail.com> 
<41EBF8C1.8070503 at tonybibbs.com> 
<8319e2d605011710386432525e at mail.gmail.com> 
<41F9AB13.3030605 at tonybibbs.com> 
<8319e2d605012808432fb2eaeb at mail.gmail.com>



Vincent Furia wrote:

>Tony,
>
>I'm just sending this to you because I'm not sure if this debate
>belongs on the list.  Feel free to move it there if you'd like.
>  
>
I'll leave it there.  I think it is a good debate so that we have a log 
of consciously deciding these things.

>It is still undefined what return value should be expected when an
>UPDATE or INSERT is done. Normally the DAO returns an array of
>classes, that doesn't make sense for UPDATEs or INSERTs.
>  
>
Updates deletes and inserts would all throw SQLExceptions.  So you would 
to do a TRY clause around them, and all database calls for that matter.  
In otherwords, no return means all went well. 

>I'm starting to get more and more concerned with speed issues for GL2.
> Between Creole being generally slow compared to other DBAPIs (by
>itself, not that big of a deal) and Propel loading/includes being very
>time intensive I'm worried adding additional layers are going to slow
>things down.
>
>All these things combine to make me want to reconsider using the DAO. 
>We also need to get to the point where we can decide if the Propel
>speed issues are going to be a problem.
>  
>
Stripping the DAO doesn't save you anything.  The Creole/Propel issues 
would still exist.  I'm not skirting the issues with the performance.  I 
fully expect that I/we will have to do true profiling at some point with 
this.  The real question I think you are asking is just how much 
overhead is the DAO and how does that compare to the benefits.

>Also, noting that the February deadline you imposed on yourself is
>looming, I'm curious if you feel work has progressed enough to keep to
>going (I feel that we're making good progress).
>  
>
Yeah, I was just thinking about this the other day.  I definitely think 
things have progressed and that we have a ton of code to show for it.  
My only worry is things stagnating again.  I'm doing to do my best to 
prevent this but getting continuing help from you and Kevin will be just 
as important of a factor.

>As I said before, I'm don't feel strongly enough about the DAO to
>force the issue.  But I think it warrants reconsideration.
>  
>
Maybe we should take the link plugin, implement it fully and do some 
serious performance analysis on it before deciding on the DAO.  That way 
we have only implemented time into one fairly minor plugin and I think 
it has enough complexity to give us an idea on performance?

I'm leary of ditching the DAO as it has proven useful in all my apps 
here at work.  Here we recently went from using raw JDBC to using 
Hibernate by simply implementing the new DAO layer and it saved us a 
bunch of time.  Granted that was Java but without going the DAO layer, 
going to Hibernate wouldn't have even have been possible.

--Tony