Deviation from object-relational mapping (pySQLFace)

[sulyokpeti at gmail.com]

On okt. 12, 19:54, Paul Boddie <p... at boddie.org.uk> wrote:
> 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

It is not convincing to look at an XML file alone. Let me give you an
example. Glade is a GTK+ application for creating GTK+ GUI. It
generates an XML file, that can be loaded in every programming
language that has libglade binding. Similarly, there could be a
database design tool to create a database, and save SQL/DML
expressions into an XML config file. Then you create the RDB command
objects by loading the XML in your favourite language. I think
programming languages are intended for describing neither relational
databases nor GUIs.