Re: [Modeling-users] API cleanup proposal

[Mario R. <ma...@ru...>]

On mercredi, juil 2, 2003, at 11:05 Europe/Amsterdam, Jerome Kerdreux 
wrote:
> Mario Ruggier wrote:
>
>
> Hum .. A general note about aliasing methods: In fact
> I use a couple of tools for test (SQLObject / MiddleKit/
> and Modeling) so as MiddleKit and Modeling try to
> monkey EOF, it use the same method names like
> insertObject() .. so for me staying closer to EOF is a good
> thing .

That would be fine. My point was that whatever method
name is preferred, then this should be the "master" and
others that do same thing are aliases. This is irrespective of
whether the preferred method name is the same as in the
EOF or not.

>>>   - make fetchCount() an alias for 
>>> objectsCountWithFetchSpecification()
>>>       [same API as fetch()]
>>
>>
>> Hmmn, I would not introduce such a specialized method (will become
>> clutter even in the short term). As suggested earlier, it may be more
>> flexible to just have a fetchSql() open method for now (that is not
>> necessarily db-independent) and that returns whatever the dbapi
>> returns.  For me nothing is gained by having 
>> fetchCount('customobjname')
>> over fetchSql('select count(*) from tblname') -- it is jn fact less 
>> flexibe.
>> When the time comes to generailize this to be db-independant, either
>> the fetch() method will gain new parameters to allow this, or other
>> generic methods introduced, such as fetchRaw, fetchTuples, fetchDicts,
>> or whatever. fetchSql can always have a use, though, so it it not 
>> likely
>> to become clutter.
>
>
> I guess you miss something Mario.
> Let's take a example .
> qualifier=qualifierWithQualifierFormat('lastName=="Hugo"')
> fetchSpec=FetchSpecification(entityName='Writer', qualifier=qualifier)
>
> fetchCount(fetchSpec) will return the number of writer with lastname = 
> 'Hugo' ..
> and so on this is not so trivial as a simple 'select count(*) ..'
>
> so the answer is no : fetchCount() and fetchSql() haven't the same 
> purpose, even
> is you can use fetSQL to do a fetchCount() or anything else.

Fair enough. fetchSQL is an open-ended convenience hack, that
allows more time to think over what a more generalized API for
fetch() could be -- so that it would handle in an OO way queries
such as qualified counts, sums, etc. I suspect that defining
a fetchCount will lead to other unnecessary definitions of other
"dedicated" methods (that could all be addressed with a well-thought
out, and simpler, fetch+ interface).

> And i really like the OO approach of modeling, and i really think that
> even fetchSQL() ( which for me should be fetchSQLObject() ) should
> alway return a object.

Yes, agreed. To achieve this, there needs to be a way to allow
"generic custom objects" to be returned by fetches, i.e. objects
that do not necessarily correspond to a class defined in a model
(such as for count, sum, ...), or, as you nicely describe below,
object that 'is not a real object but only a "result object"'.

>
> Take a look at this:
> - in the model you describe the object mapping (which is not a real 
> object
>   but only a "result object" .    for example:
>    CustomSearch
>           - searchString()
>           - books relation one-> many
>           - ...
> - I thinks we should find a way to do
> ec.objectsWithFetchSpecification('CustomSearch, ..searchString = 
> 'Toto') ..
> and so provide a method to do some special SQL in the CustomSearch()  
> which
> return CustomSearch object.
>
> But this way you can do something like
> search = CustomSearch(...)
> books = search.getBooks() ( which return some books object .. not raw 
> SQL)

Absolutely. It would be wonderful to have fetch API also be able
to handle this. The question is how to generalize the API to achieve
all these features (plus be easily extensible) while keeping it as
simple as possible.

mario