TG's reliance on Activemapper
Arnar Birgisson
bumping into stuff where the identity/visit code seems to assume the
classes are ActiveMapper classes. One example is this line in
saprovider:
visit = visit_class.get_by(visit_key = self.visit_key)
.get_by is a method added by ActiveMapper. Better would be to use
session.query(visit_class).get_by - which works with ActiveMapper
classes and "plain" SA classes.
Is anyone working on a patch to remove those ActiveMapper dependencies?
Arnar
Jorge Vargas
hi Amar while creating the support for SA 2.0 it was discuss whether to use or not ActiveMapper, the conclusion was to use it whenever it was resonable but not force anyone to it.
so if you don't want/need it don't use it. as for TG internals the reason ActiveMapper is still there is because it will make migrations from SO easier.
As for taking it out it isn't hurting anybody rigth?
Arnar
Tim Lesher
>
> > so if you don't want/need it don't use it. as for TG internals the reason ActiveMapper is still there is because it will make migrations from SO easier.
> >
> > As for taking it out it isn't hurting anybody rigth?
In the case of Identity, I have to agree with Arnar. It seems that
the most common use case for Identity is going to be writing your own
Identity classes, starting from the auto-generated ones. That's
pretty much the reason Identity was changed to generate classes in the
project's model, rather than having "standard" classes that just get
imported.
If a developer wants to create the rest of his model using straight
SA, and TurboGears claims to support that, then TurboGears shouldn't
force the developer to do it differently for Identity--particularly
when it's not difficult to code Identity in a way that works with both
styles.
Jorge Vargas
On 7/22/06, Jorge Vargas <jorge....@gmail.com> wrote:
>
> > so if you don't want/need it don't use it. as for TG internals the reason ActiveMapper is still there is because it will make migrations from SO easier.
> >
> > As for taking it out it isn't hurting anybody rigth?
don't take me wrong I'm on your side my approach to this was make active mapper optional everywhere
In the case of Identity, I have to agree with Arnar. It seems that
the most common use case for Identity is going to be writing your own
Identity classes, starting from the auto-generated ones. That's
pretty much the reason Identity was changed to generate classes in the
project's model, rather than having "standard" classes that just get
imported.
yes in fact all other ways are deprecated
If a developer wants to create the rest of his model using straight
SA, and TurboGears claims to support that, then TurboGears shouldn't
force the developer to do it differently for Identity--particularly
when it's not difficult to code Identity in a way that works with both
styles.
from where I see it now, you can just take those out as part of the mall changes made to identity I beleive visit was taken to the model also. looking at the code generator files it makes sence for the request to be there since the classes extend ActiveMapper
http://trac.turbogears.org/turbogears/browser/tags/0.9a8/turbogears/qstemplates/quickstart/%2Bpackage%2B/model.py_tmpl
the solution right now is simple.
#1 create a new quickstart template http://trac.turbogears.org/turbogears/wiki/ExtendingQuickstart
#2 create a new SqlAlchemyIdentityProvider in fact I think all that needs to be done is extend the original one and overwrite validate_identity
Arnar Birgisson
On 7/22/06, Jorge Vargas <jorge....@gmail.com> wrote:
> hi Amar while creating the support for SA 2.0 it was discuss whether to use
> or not ActiveMapper, the conclusion was to use it whenever it was resonable
> but not force anyone to it.
Using Activemapper for generated classes is fine, and I agree totally
with that decision. However, I shouldn't have to mess with the
IdentityProvider or the VisitManager.
The problem is that those classes use ActiveMapper idioms when calling
the user-provided classes, such as the get_by and get methods. Now,
it's easy to provide those on hand-written classes, but shouldn't be
neccessary.
In identity/saprovider.py - I changed
"visit_class.get_by(visit_key=self.visit_key)" to
"session.query(visit_class).get_by(visit_key=self.visit_key)" (and the
same for other classes). That seemed sufficient and it doesn't hurt
ActiveMapper classes. Of course, unless this makes it into TG source
code, I have to make this change myself each time I upgrade TG.
Arnar
Arnar Birgisson
> In identity/saprovider.py - I changed
> "visit_class.get_by(visit_key=self.visit_key)" to
> "session.query(visit_class).get_by(visit_key=self.visit_key)" (and the
> same for other classes). That seemed sufficient and it doesn't hurt
> ActiveMapper classes. Of course, unless this makes it into TG source
> code, I have to make this change myself each time I upgrade TG.
I posted a patch for this in trac, #1041
Arnar