[storm] Meta data

[Gerdus van Zyl]

I have read the blog post and discussion on the list and there are
some valid points against schema generation. It has however worked
very well everywhere I have used it with changes that was just table
creation and column addition. Yes I am doing database schema
generation but with a version table and before and after migrate
hooks.

What I am doing with the meta data that's different is generating C#
classes that have compatible datatypes as the database, interacting
with the server via rest webservice. The meta data is to add some
niceties like validation and length checking and only allowing
searching on indexed columns.

So if it's against the storm design philosophy to add then it's fine,
I'll just patch my local version :-) I only brought it up since it's a
one line change that would allow other people to build things on top
of storm that should not be part of the core.

~Gerdus

On Wed, Jul 9, 2008 at 8:35 AM, James Henstridge <james at jamesh.id.au> wrote:
> On Tue, Jul 8, 2008 at 11:52 PM, Gerdus van Zyl <gerdusvanzyl at gmail.com> wrote:
>> I am trying to store all database column information in the storm
>> column object. Eg. size of varchar columns, decimal precision, is this
>> column included in an index, default value in database, etc.
>
> If you are trying to generate database schemas from the Python
> classes, I'd recommend against it.  I wrote a bit on the subject here:
>
>    http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/
>
>
>> Note that i use the existing _variable_kwargs dictionary of Property
>> class, the code i posted was just so that storm doesn't throw an
>> exception on creating the variable class because of an unknown keyword
>> argument. (so self._extrakwargs = otherkwargs in my posted code can be
>> removed, it's not necessary, just the **otherkwargs)
>
> Storing things on the Property makes a lot more sense than on
> Variable, but as I said above it probably isn't what you want in the
> long run.
>
> James.
>