Re: [Springframework-developer] JdbcTemplate

[<tri...@tr...>]

Option 2 is OK by me.  I'll start working on this, and unless there is a lot of
opposition, I'll committ these changes early next week.

Thomas


> There's a similar issue with a Hibernate Session or a JDO PersistenceManager:
> Data access code is not supposed close, beginTransaction, etc on them. If we
> would use respective wrappers for those too, we would have to keep those
> wrappers in sync with the respective interfaces. As this strategy doesn't
> even deliver obvious restrictions at development time but just at runtime, I
> consider it not worth the effort.
>  
> Thus, I'm for 2 too: Just use the original objects, dissolve
> ReadOnlyResultSet, and put the restrictions in JavaDoc. Thomas, if everybody
> agrees with this, can you apply these changes together with the
> exception/close fixes ASAP? I'm keen on releasing 1.0 M1 in two weeks at the
> latest.
>  
> Juergen
>  
>  
> 
> 	-----Ursprüngliche Nachricht----- 
> 	Von: Rod Johnson [mailto:rod...@in...] 
> 	Gesendet: Sa 16.08.2003 11:12 
> 	An: spr...@li... 
> 	Cc: Thomas Risberg 
> 	Betreff: [Springframework-developer] JdbcTemplate
> 	
> 	
> 
> 	All,
> 	
> 	A user has suggested in the forums that we should have an option where the
> 	ResultSet isn't read only in JdbcTemplate. For example, to allow the use of
> 	updateable result sets.
> 	
> 	I wanted to use an Oracle-specific method recently, so I added the
> 	getUnderlyingResultSet() method (in 0.9.1).
> 	
> 	However, I think there probably is a need to address this in general.
> 	
> 	Some thoughts on options:
> 	
> 	1. Add boolean property to JdbcTemplate controlling whether to return the
> 	real result set. Of course this would affect all uses, not just the single
> 	case that needed it
> 	2. Remove ReadOnlyResultSet and give the user a ResultSet as in the
> original
> 	version. I'm not into the idea of constraining people in general, and I
> 	wasn't specially bothered about the possibility of the user calling "bad"
> 	methods. Maybe we could improve the Javadoc to really make it clear which
> 	methods are acceptable.
> 	3. Let more methods through in ReadOnlyResultSet. Only the navigation
> 	methods should really be off limits.
> 	4. Replace ReadOnlyResultSet with an AOP-advised proxy to the real result
> 	set, which would allow a pointcut to specify which methods are allowed and
> 	which should through UnsupportedOperationException(). This might have a
> 	small impact on performance, and would complicate stack traces, so although
> 	I think it would work well I doubt it's very wise.
> 	
> 	I'd probably chose 2 (simplicity is good!) but let's vote on it.
> 	
> 	Btw I think mock object based tests should give us a good way of ensuring
> 	that our connection, statement and result set closure is correct. I think
> 	this is also something we need to get bulletproof before 1.0.
> 	
> 	I'm leaving for Colorado for an Enterprise Architecture Summit this
> 	afternoon and will be effectively offline till Wed 27th.
> 	
> 	Regards,
> 	Rod
> 	
> 	
> 	
> 	
> 	-------------------------------------------------------
> 	This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> 	Data Reports, E-commerce, Portals, and Forums are available now.
> 	Download today and enter to win an XBOX or Visual Studio .NET.
> 	http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> 	_______________________________________________
> 	Springframework-developer mailing list
> 	Spr...@li...
> 	https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 	
> 
>
N¬HS^µéšŠ[)¢{(­ç[ÈZÞzšÞn襴4DìŠ×¬Šw%¹Ø§€6­i©¢»lÊ&™êÜxú+µ©ljwE¢»¦±ªÞjö¢•¦åzz0Œ'–†¶‡ZÉ©Ýz{^®Ú0Šv§\—¢µb²æ¥J۝ŠƒDNm§ÿÚ²™ÞµÉbrK«•Ê&þ
>
?¦Æ´Ó]4ÓMÚ½ï݊·œµ«Z²™Þ·NößMô×ý5Jšâžëjg°¢¹z÷¥¢—«™¨¥Šx%ŠËR¦¸§úڙì(®G^½éh¥êåŠËl²‹«qç讧zØm¶›?þX¬¶Ë(º·~Šàzw­þX¬¶ÏåŠËbú?²šâžëjg°¢¹z÷¥¢—«