Well, using the mapper event would be nicer, but in any case I was already
iterating over Base.classes and adding them to my own module's namespace like
so:
globals()[cls.__name__] = cls
It works for the rest of my application being able to see the classes by
importing the module, but apparently not for this. I'm not really expert at
Python class and namespace innards, but from the error message as well as the
default str() output it seems the automap-generated classes considers
themselves to be in the sqlalchemy.ext.automap module but are not registered in
that namespace.
Is there a way to tell the classes to use a different namespace from an
instrument_class handler? (And incidentally I'm already using my own base
class through automap_base(declarative_base(cls=...)) but that doesn't make any
difference.)
On 2014.2.6, at 15:59, Michael Bayer <mike...@zzzcomputing.com> wrote:
> Python pickle can't pickle class instances where the class isn't locatable as
> module-level imports. As automap necessarily creates classes on the fly,
> these classes aren't part of any module. to have them part of a module you'd
> want to use an event to place them in the namespace of one of your own
> modules, or you can implement a custom `__reduce__()` method on them (see the
> Python docs for __reduce__()).
>
> a good event to use here might be instrument_class:
>
> http://docs.sqlalchemy.org/en/rel_0_9/orm/events.html#sqlalchemy.orm.events.MapperEvents.instrument_class
>
>
>
> On Feb 6, 2014, at 4:32 AM, Adrian Robert <adrian.b.rob...@gmail.com> wrote:
>
>> One other point, I was trying out the dogpile cache example and ran into
>> (after I stuck a ".encode('utf-8')" into the key mangler since I'm using
>> Python-3 and pylibmc):
>>
>> _pickle.PicklingError: Can't pickle <class 'sqlalchemy.ext.automap.Person'>:
>> attribute lookup sqlalchemy.ext.automap.Person failed
>>
>> This was fixed by a hack
>>
>> sqlalchemy.ext.automap.__dict__[cls.__name__] = cls
>>
>> run over all the automap-created classes. It might be I'm only having to do
>> this because I'm doing something wrong elsewhere, but I just thought I'd
>> mention it in case it comes up for someone.
>>
>>
>>
>> On 2014.2.2, at 14:22, Adrian Robert <adrian.b.rob...@gmail.com> wrote:
>>
>>> Thanks, that works beautifully.
>>>
>>> I had noticed name_for_scalar_relationship parameter but I guess wasn't
>>> confident enough that I understood what was going on to try it. :-[
>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "sqlalchemy" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/sqlalchemy/p6YkPuCs_Ks/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> sqlalchemy+unsubscr...@googlegroups.com.
>>> To post to this group, send email to sqlalchemy@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/sqlalchemy.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sqlalchemy+unsubscr...@googlegroups.com.
>> To post to this group, send email to sqlalchemy@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sqlalchemy.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/groups/opt_out.
