search

zzzeek / sqla_issue_test

1 stars 0 forks source link

mapper.options() is sucky #55

Closed zzzeek closed 6 years ago

zzzeek commented 18 years ago

Originally reported by: Michael Bayer (Bitbucket: zzzeek, GitHub: zzzeek)

tried an example like this:

mapper.options(eagerload('foo'), eagerload('bar'), eagerload('foo.bar'), eagerload('bar.lala'), ...)

it didnt seem to work, and even if it did Im not completely sure that its not creating properties and then throwing them away, etc. dig into this and see how its really working, look into smarter ways (like checking each properties parent mapper before deciding to copy it)

zzzeek commented 18 years ago

Original comment by Michael Bayer (Bitbucket: zzzeek, GitHub: zzzeek):

this bug is sort of dead for now. reopen if theres any reported issues with options(), its been working fine.

zzzeek commented 18 years ago

Original comment by Michael Bayer (Bitbucket: zzzeek, GitHub: zzzeek):

yes, the MapperOption would have to detect the list and spawn out a list of EagerLazyOption objects, and use those.

zzzeek commented 18 years ago

Original comment by Anonymous:

(original author: Justin) could the syntax be

mapper.options(eagerload(['foo','bar','foo.bar','bar.lala']('foo','bar','foo.bar','bar.lala')))
zzzeek commented 18 years ago

Original comment by Michael Bayer (Bitbucket: zzzeek, GitHub: zzzeek):

this was improved a bunch of changesets ago when the "mapper singleton" behavior was removed for the more lightweight way it is now. still should go thorugh and see if it really works and that its not making lots of excess objects (or maybe it is and who cares). so bumping priority down.