[kforge-dev] Is SQLObject more than an ORM?

[Rufus Pollock]

Dear John,

In response to various comments in your last email here is a summary of 
my thoughs on SQLObject and 'domain model toolkits'. Do remember when 
reading it that I am *not* advocating any particular position but simply 
seeking, often via questions, to understand better our own system and 
the reasons for it being the way it is.

Regards,

Rufus

## Introduction

First I would like to make clear that I entirely agree that one should 
not build a domain model using a object-relational mapper (ORM) and that 
one needs to build some form of domain model toolkit on top of the ORM. 
The point I am trying to raise about SQLObject is that while called 
SQLObject and often referred to as an ORM it is in fact more than an 
ORM, in fact a fairly good domain model toolkit. The distinction can 
perhaps best be seen by comparing SQLObject and SQLAlchemy. SQLAlchemy 
really *is* a pure ORM (as demonstrated by the fact that people are 
developing a domain-model like toolkit on top of it, see e.g. [Jonathan 
La Cour's implementation of an Active Record type pattern][1]).

[1]: http://cleverdevil.org/computing/35/declarative-mapping-with-sqlalchemy

I agree that SQLObject carries over some SQL stuff into its domain-model 
toolkit most prominently in its naming of attributes (StringCol, IntCol, 
ForeignKey etc) but my question would be: while this is annoying do we 
need to create a new toolkit just to get round this[^1]? (I want to 
emphasize here that I am genuinely asking a question here, not 
criticizing what we have done). Of course this question pressupposed 
that SQLObject is a fairly close fit for what we require and only lacks 
the correct naming etc. Thus I should better put this as two separate 
questions:

   1. Suppose SQLObject while not an exact fit for the domain object 
toolkit we have in mind provided a substantial portion of the 
functionality required. Would it not then be better to use and adapt 
SQLObject rather than create own our toolkit? This would save us having 
to create our own stuff from scratch as well as benefitting from the 
large existing community using SQLObject.

    Here we have the classic trade-off between rolling-your-own and 
using-an-existing-package. Using SQLObject we must suffer from its warts 
and deficiencies while if we roll-our-own we have a clean slate and can, 
to an extent, write exactly what we want. On the other side we alone 
work on our own code which reduces the speed of development, reduces 
those available to bugfix etc (I note that, as discussed a while back, 
our dom toolkit is currently missing HasMany to HasMany relations 
(equivalent to MultipleJoin in SQLObject) and the uniqueness constraint 
for names in NamedDomainObject does not seem to be operable).

   2. Does SQLObject, in fact, provide a 'substantial portion of the 
functionality' (and does it have the correct structure and interface)?

To give some substance for discussion on this second point here is a 
comparison of our current code and (my attempt at a) rendering in 
SQLObject:

# kforge.dom.project
class Project(StandardObject):
     "Registered project."

     searchAttributeNames = ['name', 'title']

     title       = String(default='')
     description = String(default='')
     licenses    = HasMany('ProjectLicense', 'license')
     members     = HasMany('Member', 'person')
     services    = HasMany('Service', 'name')

     # class methods

# sqlobject version
class Project(sqlobject.SQLObject):

     title       = StringCol(default='')
     description = StringCol(default='')
     licenses    = RelatedJoin('License')
     members     = MultipleJoin('Member')
     services    = MultipleJoin('Service')

## Comparison Summary

SQLObject 'dom'

   * Inheritance via
     1. Concrete Table Inheritance (but does not allow multiple inheritance)
     2. ... Inheritance (sqlobject.inheritable)
   * weird behaviour for __init__ (John: you know the details of this)
   * naming derived from SQL

DomainModel dom:

   * Inheritance via concrete table inheritance pattern supporting 
multiple inheritance
   * Richer registry setup (with special keying -- john perhaps you 
could provide more detail here)
   * naming derived from object-oriented design

## Conclusion

I've suggested that SQLObject is more than just a ORM and, in fact, 
possesses some of the features of domain object toolkit. Of course it 
may still be unsatisfactory for us to use it in that way something I 
tried to bring out in the two questions I posed. I've provided a 
comparison of SQLObject and our toolkit with a very limited (and 
probably inaccurate) summary. I'd welcome your comments on the summary 
be they criticisms or additions!

Finally, I'd like to suggest that, if we do wish to keep our own domain 
model toolkit, that we submit our work back to SQLObject (and perhaps to 
SQLAlchemy?) for inclusion in the package.

## Footnotes

[^1]: If necessary we could just inherit from these objects to rename 
them e.g.:

class HasA(ForeignKey):

   ....