How to use history_meta.py (VersionedMeta) and migrate together to change schema on both main table and history table?

Does any one have any examples of how to combine sqlalchemy's migrate
to control the database with history from VersionedMeta?

I'm able to use either, but don't really know the best practices for
combining the two.

For example, once I create my table (Equipment) in SQLAlchemy with my
first migrate script using the

Base = declarative_base(metaclass=VersionedMeta)

in my migrate script, what's the best way to add a column to that
table in future migrate scripts?

I was able to add a new column to the Equipment Table in my 2nd
migrate script:

    col = Column('newcol',Text, default='foobar')
    col.create(Equipment.__table__,populate_default=True)

but it is not reflected in the corresponding equipment_history table
that VersionedMeta created.

What's the best way to combine these 2 technologies to update the
associated _history table from a migration script?

Thanks,
-Jim

--

-- 

Adapting the polymorphic association example for generic reuse

I am looking at http://www.sqlalchemy.org/trac/browser/examples/generic_associations/discriminator_on_association.py
and trying to adapt the example to one that is generic and can be
reused. So I attempted to abstract all the classes. However there
seems to be an error in the __new__ function of the creator object.

CODE is here
http://pastebin.com/4DyK47r3

ERROR is here:
Traceback (most recent call last):
File "sqlalchemyex.py", line 136, in <module>
    zip="95732")
File "<string>", line 4, in __init__
File "/home/ahmed/dev/pyrenv/lib/python2.6/site-packages/
SQLAlchemy-0.6.6-py2.6.egg/sqlalchemy/orm/state.py", line 111, in
initialize_instance
    return manager.events.original_init(*mixed[1:], **kwargs)
File "/home/ahmed/dev/pyrenv/lib/python2.6/site-packages/
SQLAlchemy-0.6.6-py2.6.egg/sqlalchemy/ext/declarative.py", line 1378,
in _declarative_constructor
    setattr(self, k, kwargs[k])
File "/home/ahmed/dev/pyrenv/lib/python2.6/site-packages/
SQLAlchemy-0.6.6-py2.6.egg/sqlalchemy/ext/associationproxy.py", line
195, in __set__
    setattr(obj, self.target_collection, creator(values))
File "sqlalchemyex.py", line 28, in <lambda>
    discriminator=discriminator)
TypeError: object.__new__() takes no parameters

Can anyone please help me understand what am I doing wrong? I guess if

Re: Adapting the polymorphic association example for generic reuse

line 21 creates an AssociationBase passing two arguments to the constructor, but AssociationBase has no
__init__ and accepts no arguments.

I'd strongly recommend using pdb to track down issues like these.

On Oct 2, 2011, at 5:26 AM, Ahmed wrote:

> I am looking at http://www.sqlalchemy.org/trac/browser/examples/generic_associations/discriminator_on_association.py
> and trying to adapt the example to one that is generic and can be
> reused. So I attempted to abstract all the classes. However there
> seems to be an error in the __new__ function of the creator object.
> 
> CODE is here
> http://pastebin.com/4DyK47r3
> 
> ERROR is here:
> Traceback (most recent call last):
> File "sqlalchemyex.py", line 136, in <module>
>    zip="95732")
> File "<string>", line 4, in __init__
> File "/home/ahmed/dev/pyrenv/lib/python2.6/site-packages/
> SQLAlchemy-0.6.6-py2.6.egg/sqlalchemy/orm/state.py", line 111, in
> initialize_instance
>    return manager.events.original_init(*mixed[1:], **kwargs)
> File "/home/ahmed/dev/pyrenv/lib/python2.6/site-packages/
> SQLAlchemy-0.6.6-py2.6.egg/sqlalchemy/ext/declarative.py", line 1378,
> in _declarative_constructor
>    setattr(self, k, kwargs[k])
> File "/home/ahmed/dev/pyrenv/lib/python2.6/site-packages/
> SQLAlchemy-0.6.6-py2.6.egg/sqlalchemy/ext/associationproxy.py", line

Impedance mismatch: too much queries?

I have an impedance mismatch problem, namely a model in X categories, 
each having its own set of fields and all having a set of common fields. 
I solved that with:

1. "master" table, contains the sequenced pkey and common fields, as 
well as "category" discriminator
2. individual category tables with fields specific to that category, and 
foreign key pkey to the master table.

I've been reading on the Joined Table Inheritance and this seems like a 
right way to do it, however I'm not quite sure I can use SQLAlchemy's 
polymorphic patterns. Here's why.

When I create new model of certain category I of course know which 
category it is, so that's not the problem. But when the system queries 
the model (a model) by ID, it does not know in advance which category it 
belongs to. So whatever I do I am forced to do two queries, first to the 
master table and then to the proper category table. AFAIK this is the 
only way to do it unless there's some SQL trick that can join tablename 
dynamically based on column value (and I don't mean triggers)?

Anyways, the problem I'm having is when I query the whole set. Each 
master-category "pair" belongs to a user, and I have to query ALL the 
models that belong to the user. So I end up querying everything from the 
master table that belongs to that user, and then FOR EACH, load up the 
belonging category model from appropriate category table. This means 
that if I had 10k rows, I'd have to issue 10k selects, next to the 
master select to pull in all 10k master table rows (and from what I 
ready psycopg2 can't yield, it has to buffer them all).

Re: Impedance mismatch: too much queries?

Ah, a solution just came to me. If I had 10 categories and denormalized 
the user_id into them, I can reverse the queries and do only 10 selects, 
filtered by user_id and joined with the master table on pkey. I'd end up 
with equal number of rows selected, but only 10 queries issued. The 
denormalized user_id would not pose any problems and I can cascade 
updates and deletes via master table, which is in cascade from the users 
table.

Thoughts?

.oO V Oo.

On 10/02/2011 04:12 PM, Vlad K. wrote:
>
> I have an impedance mismatch problem, namely a model in X categories, 
> each having its own set of fields and all having a set of common 
> fields. I solved that with:
>
> 1. "master" table, contains the sequenced pkey and common fields, as 
> well as "category" discriminator
> 2. individual category tables with fields specific to that category, 
> and foreign key pkey to the master table.
>
> I've been reading on the Joined Table Inheritance and this seems like 
> a right way to do it, however I'm not quite sure I can use 
> SQLAlchemy's polymorphic patterns. Here's why.
>
> When I create new model of certain category I of course know which 
> category it is, so that's not the problem. But when the system queries 

Re: Impedance mismatch: too much queries?

On Oct 2, 2011, at 10:27 AM, Vlad K. wrote:

> 
> Ah, a solution just came to me. If I had 10 categories and denormalized the user_id into them, I can reverse
the queries and do only 10 selects, filtered by user_id and joined with the master table on pkey. I'd end up
with equal number of rows selected, but only 10 queries issued. The denormalized user_id would not pose
any problems and I can cascade updates and deletes via master table, which is in cascade from the users table.

You can do that, or put all ten queries together into a UNION.  That's what the polymorphic_union() function
can produce for you, mentioned here:
http://www.sqlalchemy.org/docs/orm/mapper_config.html?highlight=polymorphic_union#sqlalchemy.orm.util.polymorphic_union
 .     It says "concrete table inheritance" but it can be used for joined-inh models as well, in conjunction
with the whole "with_polymoprhic" system.   

The other way as you can see in the docs there is to OUTER JOIN to all the tables, which depending on various
things may or may not be more/less efficient/easy than the UNION approach.

> 
> Thoughts?
> 
> 
> .oO V Oo.
> 
> 
> On 10/02/2011 04:12 PM, Vlad K. wrote:
>> 
>> I have an impedance mismatch problem, namely a model in X categories, each having its own set of fields and
all having a set of common fields. I solved that with:
>> 

packages, modules and double imports - oh my!

Hi All,

The attached package gives that smallest possible example of problems 
I'm hitting with some SQLAlchemy declarative classes.

In short, I want to be able to do:

python -m pack.module and have if the __name__=='__main__' block spit 
out the SQL to create the tables necessary for the modules in that class...

So, using the attached package to demonstrate, the first problem I get is:

cwithers <at> cwlin:~> python -m pack.module
Traceback (most recent call last):
    File "/usr/lib64/python2.6/runpy.py", line 121, in _run_module_as_main
      "__main__", fname, loader, pkg_name)
    File "/usr/lib64/python2.6/runpy.py", line 34, in _run_code
      exec code in run_globals
    File "/home/cwithers/pack/module.py", line 3, in <module>
      class MyClass(object):
    File "pack/__init__.py", line 7, in __init__
      raise Exception('%r registered twice' % self.__name__)
Exception: 'MyClass' registered twice

Looks like I have a pack.module.MyClass and a __main__.MyClass, which 
feels like a bug to me...

Ho hum, lets try something different:

cwithers <at> cwlin:~> python pack/module.py

Re: packages, modules and double imports - oh my!

ive no idea what __main__.py is either ?   where's the SQLAlchemy exceptions here ?  (keeping in mind i havent
yet gone through all the steps to download a file...untar it...figure out what you're trying to do...)  

On Oct 3, 2011, at 6:11 AM, Chris Withers wrote:

> Hi All,
> 
> The attached package gives that smallest possible example of problems I'm hitting with some SQLAlchemy
declarative classes.
> 
> In short, I want to be able to do:
> 
> python -m pack.module and have if the __name__=='__main__' block spit out the SQL to create the tables
necessary for the modules in that class...
> 
> So, using the attached package to demonstrate, the first problem I get is:
> 
> cwithers <at> cwlin:~> python -m pack.module
> Traceback (most recent call last):
>   File "/usr/lib64/python2.6/runpy.py", line 121, in _run_module_as_main
>     "__main__", fname, loader, pkg_name)
>   File "/usr/lib64/python2.6/runpy.py", line 34, in _run_code
>     exec code in run_globals
>   File "/home/cwithers/pack/module.py", line 3, in <module>
>     class MyClass(object):
>   File "pack/__init__.py", line 7, in __init__
>     raise Exception('%r registered twice' % self.__name__)
> Exception: 'MyClass' registered twice
> 
> Looks like I have a pack.module.MyClass and a __main__.MyClass, which feels like a bug to me...

Re: packages, modules and double imports - oh my!

On 03/10/2011 15:15, Michael Bayer wrote:
> ive no idea what __main__.py is either ?   where's the SQLAlchemy exceptions here ?  (keeping in mind i havent
yet gone through all the steps to download a file...untar it...figure out what you're trying to do...)

The attached .tgz simplifies the real process, since this is a Python 
issue not a SA one...

The SA bit is that Declarative barfs 'cos the class is processed twice...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

--

-- 
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To post to this group, send email to sqlalchemy <at> googlegroups.com.
To unsubscribe from this group, send email to sqlalchemy+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.

Re: packages, modules and double imports - oh my!