Deviation from object-relational mapping (pySQLFace)

[Paul Boddie]

On 12 Okt, 17:19, sulyokp... at gmail.com wrote:
> I have made a simple python module to handle SQL databases:
> https://fedorahosted.org/pySQLFace/wiki
> Its goal to separate relational database stuff (SQL) from algorythmic
> code (python). A SQLFace is a facade initialized with a configuration
> file (XML). It provides callable command objects for each sql query.
> The call substitutes template variables with its parameters, and
> returns the result of the query.
> I would like to get some opinions on this approach.

Not being a fan of object-relational mappers myself, I think that it's
worthwhile to explore other avenues that make database access more
convenient than plain DB-API usage, yet to still expose the benefits
of the database technology. I think that focusing on queries and
operations is the right thing to do, rather than to place the database
schema in a central position like most object-relational mappers do,
and I think that you've made the right decision in preserving the
queries instead of trying to erase all traces of SQL, but I'm not too
convinced by the usage of XML: what I've done myself in various
applications is to define query classes which declare the outputs from
each query as a list stored in a class attribute - something like
this:

class WeatherQuery(Query):

  outputs = ["city", "temp_lo", "temp_hi", "prcp", "date"]
  query = "SELECT city,temp_lo,temp_hi,prcp,date FROM weather"

Naturally, the superclass provides support for the actual query
execution, production of different output representations (such as
XML), and so on. If I wanted to make this more automatic (to stop
people squealing about "DRY" and the repetition of the column names,
although the outputs need not have the same names as the columns), I'd
probably want to parse the SQL (within reason, of course, since SQL is
quite a big language once you start to consider all the different
features).

Still, I don't think there's much to choose between what you've done
and what I've described above, and I think that there's definitely
merit in your approach.

Paul