[sr-dev] SF.net SVN: openser:[5928] branches/1.5/modules/permissions/trusted.c

Alex Balashov abalashov at evaristesys.com
Fri Oct 2 09:59:34 CEST 2009


Alex Balashov wrote:
> Iñaki Baz Castillo wrote:
> 
>> El Viernes, 2 de Octubre de 2009, Alex Balashov escribió:
>>> � wrote:
>>>> El Viernes, 2 de Octubre de 2009, Juha Heinanen escribi�:
>>>>> Revision: 5928
>>>>>           
>>>>> http://openser.svn.sourceforge.net/openser/?rev=5928&view=rev
>>>>> Author:   juhe
>>>>> Date:     2009-10-02 04:51:57 +0000 (Fri, 02 Oct 2009)
>>>>>
>>>>> Log Message:
>>>>> -----------
>>>>> * Check that db connection exists before trying to make query.
>>>>> * Do not close db connection if db query fails.
>>>> Isn't this stuf handled by db_xxxxx modules?
>>> That's what I thought, but evidently not, because results vary depending
>>> on which module is doing the calling.
>>
>> I really fail to understand why a module using a DB backend should 
>> handle the DB connection... ¿?
> 
> I haven't looked at the code, but I suspect that the calling module does 
> not "handle" the DB connection in any direct sense, but rather 
> indirectly through an interface exposed to it by the DB backend module.
> 
> This problem probably cannot be entirely avoided;  even if the mechanics 
> of database interaction are hidden in db_*, some manipulation of 
> abstractions - which correspond to underlying database handle and query 
> states, etc. - by modules that use db_* is probably required, just like 
> with any API.  And just like any caller of an API, it is possible for 
> the calling module to misbehave on exceptional conditions returned by 
> the lower-level DB module.
> 
> I would agree, however, that db_* should probably provide enough 
> containment and error handling to prevent all but the most egregious 
> database-related fatal runtime errors.

Also, keep in mind that the bulk of the permissions module was written 
in 2003.  It is possible that it uses more extensive and low-level 
database interaction approaches from a time when the functional 
decomposition and modularisation of all this stuff was not where it was 
today.

-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671



More information about the sr-dev mailing list