On 6/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > http://sluggo.scrapping.cc/python/sacontext/
> >
> hmm, why have i invented same thing 8 months ago...
> Anyway. for a reason or another u dont have any "destroy" operations
> there.
It's only a container. Its main job is to preserve the right
relationships between the engines/metadatas/sessions. It doesn't do
any data modifications itself.
> def destroy_tables( me):
> me.metadata.drop_all()
> def create_tables( me):
> me.metadata.create_all()
In this case the user would explicitly do "sac.metadata.drop_all()".
I don't see a need to encapsulate this further.
> Here some i've found useful so far (sorry, not immediately usable):
> --------------
> def destroy( me, full =True):
> me.session.close()
>
> #SA caches/data
> sqlalchemy.clear_mappers()
>
> try: me.metadata.drop_all()
> except AttributeError: pass
> me.metadata = None
> if full:
> try: me.db.dispose()
> except AttributeError: pass
> me.db = None
>
> #from sqlalchemy.orm import mapperlib
> #mapperlib.global_extensions[:] = []
> #more?
> def detach_instances( namespace_or_iterable, idname ='id'):
> 'useful to completely get rid of any SA sideeffects/artefacts,
> e.g. for testing'
> try: itervalues = namespace_or_iterable.itervalues() #if dict-like
> except AttributeError: itervalues = namespace_or_iterable
> for e in itervalues:
> try: del e._instance_key
> except AttributeError: pass
> setattr( e, idname, None) #or delattr ??
These may be useful in a library of SQLAlchemy utility functions but
they're outside SAContext's scope. SAContext doesn't contain mappers
so it shouldn't be clearing them. Likewise it doesn't contain tables
or ORM object. The reason it doesn't contain these is that SQLAlchemy
provides other nice constructs for those:
- users normally have a global variable for each table
- if you don't, you can retrieve a table with Table("tablename")
- tables are heavily used in expressions, and
sac.tables["tablename"].c is too verbose
- users normally don't keep direct references to mappers
- you can retrieve a mapper if you need to via some syntax I can't
be bothered to look up
- ORM objects work fine as-is
However, there's no reason you can't write a SuperSAContext subclass
with lots of data-management features, and publish it if you like.
But don't these "destroy everything" scenarios mainly occur during
interactive debugging and experimentation? Where in an application
would you want to clear mappers, detach an object with no traces left
behind (aren't session.clear() and session.expunge() good enough?), or
destroy everything?
> One thing i'm still not sure, if i can rebind a (now bound) metadata
> to another engine, how that affect mappers etc. i.e. how all these
> lifetimes (engines, metadatas, mappers) actualy interact.
In SAContext with the default strategy, the metadatas are expected to
remain bound to their original engines. If you reconnect one to a
different engine, I don't know, maybe it'll work. I can make an
engineless subclass with unbound metadatas if enough people really
need it.
As far as I understand it, when you do an operation that must access
the database *now*, it cascades down through the chain looking for a
Connection. Starting with the method args, down through the session
to the mapped class to the mapper, to the table to the metadata to the
engine, which provides a Connection. Of course you start at a
different level depending on what kind of method you call. Various
points in the chain may contain an Engine, and if so it uses that one.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
