[storm] proposal for improvement

[Thomas K.]

Hello Gustavo and list,

it's thursday and a holiday here (some countries in germany) AND I have 
time to answer your questions ... ;-)

> Have you thought about what kind of parameters we could add that would
> make it possible to build that kind of extension on top of Storm,
> without necessarily introducing the knowledge of all extensions into
> Storm itself?

I'll split my answer in 2 parts (and with the parallel thread "Moving 
storm forward" in mind):

As Jean Daniel and Vernon Cole remarked: Storm is a framework to "use" 
db tables with SQL. Creation and modification (and other tasks) of 
tables are a huge field with many traps. I agree, that it is wise to 
hold Storm, as it is now, separated from such things. The reason is: 
there are many SQL database systems, which use a unique way to query 
data, but with many different features and goals, which are reflected in 
the way, for example, how tables will be created or modified to use such 
features.

Not to go to deep into details: there are many SQL databases which can 
(potential) used with Storm. But all with some different goals and 
features. Querying is mostly standardisized. Creating and modifying of 
tables depend much more on used database adapter. It's not a good idea 
to introduce all possible attributes BY NAME into Storm to describe a 
table column. You would get every day a change, especially this would be
a change in interface! (and this is the death for a production 
environment, I have enough experiences with such. If you really like 
trouble, do this! But beware, you will get more trouble as you can eat! 
;-) )

As we can learn: :-)) It's wise to hold querying functionality (as Storm 
now) separated from functionality to create or modify tables. But there 
is one thing in common: the table description! And - also my experience 
- it's not a good idea to hold a definition of something in 2 or more 
places. You will find at least one, which forget at least one part to 
change to hold all consistent.

And that's part 2 of my answer: how to introduce all the possible 
attributes for a table column (sorry Stephen, I havn't looked on zope 
schema till now, so I can't compare it against this. Maybe zope schema 
is able to make the job describing a table for Storm and not to have a 
part of description in zope schema and another part as table class for 
Storm) Goal should be, to hold the definition in one place, this is (in 
the moment!) the definition of the table class.

First example (as my proposal and identical from Gerdus van Zyl)::

   class Table(object):
     __storm_table__ = "table1"
     col1 = Int(primary = True, notNull = True)
     col2 = Unicode(size = 10)

(this is to see as an example to explain the solution) The attributes 
notNull on col1 and size on col2 describe ADDITIONAL attributes. This 
need a change on Variable class to catch up this additional attributes 
there. They could be used in Variable class (as for example the size 
attribute in the example below to provide a length check), but mostly 
they will not be used there. But it needs a change in Storm!

Second example (following Gustavo's suggestion in his post)::

   class Table(object):
     __storm_table__ = "table1"
     col1 = ColAttribute(Int(primary = True), notNull = True)
     col2 = ColAttribute(Unicode(), size = 10)
     col3 = Unicode() # as example, that ColAttribute isn't necessary!

This makes the same as the first example (and my and Gerdus suggestion). 
It's (in my opinion) not so elegant as the first example, but will do 
the same job. Implementation is not much more difficult and the biggest 
advantage: there is no need to change or adapt Storm! It can be made 
completely outside of Storm as a real extension. Here is the possible 
(rough) implementation of ColAttribute::

   def ColAttribute(colprop, **attrs):
     colprop.extraAttributes = attrs
     return colprop

To make the life more easy, it's possible to create more specialized 
functions, wich do at least the same (for example)::

    col1 = NotNull(Int(primary = True))

Hope this helps. Especially for Gerdus, which has developed the same 
solution as me. (as it looks so)

cu, Thomas