ActiveMapper vs. straight SQLAlchemy for identity
Kevin Dangoor
from using ActiveMapper for the identity classes to using the straight
SQLAlchemy model. The argument that I can see for making that change
is that ActiveMapper is an "extension", so it's not quite as supported
as the standard data mapper approach. The disadvantage is that it's
more verbose and may not be as easy to grok for new users.
What opinions do you all have?
BTW, I'm also thinking that we should just remove the identity model
classes from saprovider.py, since they're not working anyhow, and just
have them in the model.py of quickstart.
Kevin
--
Kevin Dangoor
TurboGears / Zesty News
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
Arnar Birgisson
> What opinions do you all have?
Personally, I would like to keep ActiveMapper out of it. I can see
your point though.
> BTW, I'm also thinking that we should just remove the identity model
> classes from saprovider.py, since they're not working anyhow, and just
> have them in the model.py of quickstart.
The model in saprovider seemed to work ok in my patch.. didn't test it
very much though.
Arnar
Kevin Dangoor
>> BTW, I'm also thinking that we should just remove the identity model
>> classes from saprovider.py, since they're not working anyhow, and
>> just
>> have them in the model.py of quickstart.
>
> The model in saprovider seemed to work ok in my patch.. didn't test it
> very much though.
What i meant was that they're not working pre-0.2 patch. I think the
identity model really does belong in model.py where people can
trivially tweak it as needed.
Kevin
Gary
> >> BTW, I'm also thinking that we should just remove the identity model
> >> classes from saprovider.py, since they're not working anyhow, and
> >> just
> >> have them in the model.py of quickstart.
> >
> > The model in saprovider seemed to work ok in my patch.. didn't test it
> > very much though.
>
> What i meant was that they're not working pre-0.2 patch. I think the
> identity model really does belong in model.py where people can
> trivially tweak it as needed.
I think that ActiveMapper should be left out of it for now. It seems to
be "experimental" or alpha at best and so likely to break Turbogears if
there is further development. The standard SA stuff is not that hard.
If people want to use ActiveMapper for their own stuff, then that is up
to them.
I would also leave the model code only in model.py and available for
tweaking there rather then have the same thing in two different places.
Regards,
Gary.
Jorge Vargas
One of the patches we have for SQLAlchemy 0.2 support in TG switches
from using ActiveMapper for the identity classes to using the straight
SQLAlchemy model. The argument that I can see for making that change
is that ActiveMapper is an "extension", so it's not quite as supported
as the standard data mapper approach. The disadvantage is that it's
more verbose and may not be as easy to grok for new users.
What opinions do you all have?
why is this based on identity only? I think we should scrap ActiveMapper all together from TG , don;t get me wrong I like the work Jonathan put in there but I think it hides the potential SA has behind the fact of making it easy for new people.
I believe the trade off between making it hard to start vs. making it hard to make complex db stuff, is better to go complex at the start because people could get flustracted saying, well TG is good for small stuff but I can't do complex SQL on it.
BTW, I'm also thinking that we should just remove the identity model
classes from saprovider.py, since they're not working anyhow, and just
have them in the model.py of quickstart.
yes they should be taken out, the only reason the ones in soprovider.py are still there is for backward compatibility
Jason Chu
"Jorge Vargas" <jorge....@gmail.com> wrote:
> On 6/15/06, Kevin Dangoor <dan...@gmail.com> wrote:
> >
> >
> > One of the patches we have for SQLAlchemy 0.2 support in TG switches
> > from using ActiveMapper for the identity classes to using the
> > straight SQLAlchemy model. The argument that I can see for making
> > that change is that ActiveMapper is an "extension", so it's not
> > quite as supported as the standard data mapper approach. The
> > disadvantage is that it's more verbose and may not be as easy to
> > grok for new users.
> >
> > What opinions do you all have?
>
>
> why is this based on identity only? I think we should scrap
> ActiveMapper all together from TG , don;t get me wrong I like the
> work Jonathan put in there but I think it hides the potential SA has
> behind the fact of making it easy for new people.
>
> I believe the trade off between making it hard to start vs. making it
> hard to make complex db stuff, is better to go complex at the start
> because people could get flustracted saying, well TG is good for
> small stuff but I can't do complex SQL on it.
>
> BTW, I'm also thinking that we should just remove the identity model
> > classes from saprovider.py, since they're not working anyhow, and
> > just have them in the model.py of quickstart.
>
>
> yes they should be taken out, the only reason the ones in
> soprovider.py are still there is for backward compatibility
Maybe I'm mistaken, but I thought that if you used something like
ActiveMapper, you could fall back to regular SA. Sort of the best of
both worlds. If that's the case, in most cases, I prefer the ease at
the beginning, but no hoops later on.
Jason
Kevin Dangoor
On 6/15/06, Kevin Dangoor <dan...@gmail.com> wrote:
One of the patches we have for SQLAlchemy 0.2 support in TG switches
from using ActiveMapper for the identity classes to using the straight
SQLAlchemy model. The argument that I can see for making that change
is that ActiveMapper is an "extension", so it's not quite as supported
as the standard data mapper approach. The disadvantage is that it's
more verbose and may not be as easy to grok for new users.
What opinions do you all have?
why is this based on identity only? I think we should scrap ActiveMapper all together from TG , don;t get me wrong I like the work Jonathan put in there but I think it hides the potential SA has behind the fact of making it easy for new people.
Jonathan LaCour
> SQLObject (and Rails' ActiveRecord) may not have as powerful a model
> as SQLAlchemy, but they are super easy to use. If you're creating
> a brand new database, the Active Record pattern can work great.
> ActiveMapper does not (or at least need not) prevent you from growing
> into all of SQLAlchemy's features as you need them. If it lets you
> get to the Table objects, you can make your own Mappers later, if you
> decide you need them.
You can indeed access the tables on your objects if you use ActiveMapper
just by saying MyClass.table. I created ActiveMapper because I wanted
SQLAlchemy to be as easy to use as Rails' ActiveRecord and SQLObject.
> The ultimate API is one that lets you start off easily and quickly and
> then work your way up in a nice, smooth progression as you need more
> capabilities. Sacrificing easy start up would discourage new users.
Yes, and this is exactly the goal of ActiveMapper. SQLAlchemy proper
is unbelievably powerful, and highly flexible. However, its not the
easiest thing to get rolling with. If you have an existing legacy schema
then it might be better to go with plain SQLAlchemy. On the other hand,
if you are starting from scratch, ActiveMapper is probably a pretty
good choice.
Any problems experienced right now with mixing ActiveMapper with plain
SQLAlchemy tables and mappers are bugs, and I would like them fixed.
In the same way, if people find things that they would like added to
ActiveMapper that are missing, I would like them added. I fully admit
that ActiveMapper is definitely experimental at this point but so is
TurboGears' support for SQLAlchemy. The only way for something to move
beyond the "experimental" stage is for people to use it, find problems
and deficiencies, and solve them.
In my opinion, plain SQLAlchemy is not an acceptable replacement for
SQLObject in TurboGears.
--
Jonathan LaCour
http://cleverdevil.org
Mark Ramm
> SQLObject in TurboGears.
Agreed, what we need is something that is as easy to get started with
as SQLObject, and as easy to scale to complex problems with as
SQLAlchemy.
ActiveMapper is a good start, and it may eventually give us the best
of both worlds. Ease of use for popular cases (make simple things
simple) and all the power you need to use wild and crazy legacy
database structures (and complex things possible).
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Jorge Vargas
On Jun 15, 2006, at 12:44 PM, Jorge Vargas wrote:On 6/15/06, Kevin Dangoor < dan...@gmail.com> wrote:
One of the patches we have for SQLAlchemy 0.2 support in TG switches
from using ActiveMapper for the identity classes to using the straight
SQLAlchemy model. The argument that I can see for making that change
is that ActiveMapper is an "extension", so it's not quite as supported
as the standard data mapper approach. The disadvantage is that it's
more verbose and may not be as easy to grok for new users.
What opinions do you all have?
why is this based on identity only? I think we should scrap ActiveMapper all together from TG , don;t get me wrong I like the work Jonathan put in there but I think it hides the potential SA has behind the fact of making it easy for new people.TG doesn't have any particular ties to ActiveMapper to be scrapped other than identity.
yes that is what I was refering, not making it require in any part of TG, so if for any reason you don't want to use it don't. On the other we may set ActiveMapper as default use so new people can dive into TG without problem but there should be docs/warnings explaining how to migrate awat from ActiveMapper, when/if the time comes.
SQLObject (and Rails' ActiveRecord) may not have as powerful a model as SQLAlchemy, but they are super easy to use. If you're creating a brand new database, the Active Record pattern can work great.
that's true, the feature I like the most of SQLObject is that I can create the tables in a quick brainstom and not worry about details, but then it starts giving troubles when columns need to be added,etc,etc.
ActiveMapper does not (or at least need not) prevent you from growing into all of SQLAlchemy's features as you need them. If it lets you get to the Table objects, you can make your own Mappers later, if you decide you need them.The ultimate API is one that lets you start off easily and quickly and then work your way up in a nice, smooth progression as you need more capabilities. Sacrificing easy start up would discourage new users.
I agree 100% although i'll prefer hard to start but flexible then easy at start and then having to work around it.
Kevin
Jorge Vargas
on my previous email I said ActiveMapper instead of ActiveRecord :)
Kevin Dangoor wrote:
> SQLObject (and Rails' ActiveRecord) may not have as powerful a model
> as SQLAlchemy, but they are super easy to use. If you're creating
> a brand new database, the Active Record pattern can work great.
> ActiveMapper does not (or at least need not) prevent you from growing
> into all of SQLAlchemy's features as you need them. If it lets you
> get to the Table objects, you can make your own Mappers later, if you
> decide you need them.
You can indeed access the tables on your objects if you use ActiveMapper
just by saying MyClass.table. I created ActiveMapper because I wanted
SQLAlchemy to be as easy to use as Rails' ActiveRecord and SQLObject.
That's great I believe ActiveRecord should never obscure the tables to a way you can't access them, if that ever happens will kill the idea and we'll be stuck with SQLObject-like problems again.
Any problems experienced right now with mixing ActiveMapper with plain
SQLAlchemy tables and mappers are bugs, and I would like them fixed.
In the same way, if people find things that they would like added to
ActiveMapper that are missing, I would like them added. I fully admit
that ActiveMapper is definitely experimental at this point but so is
TurboGears' support for SQLAlchemy.
and TG itself :)
The only way for something to move beyond the "experimental" stage is for people to use it, find problems
and deficiencies, and solve them.
yes your right, now that we almost have support for 0.2 I'll probably migrate a couple of things to it, and I'll try to use the ActiveMapper when I can.
In my opinion, plain SQLAlchemy is not an acceptable replacement for
SQLObject in TurboGears.
I believe it is, although some help from ActiveMapper will be welcome for some people but not for everyone.
TG will always have a problem with this kind of thing, we are a framework of the best of the best, and of course they are many best out there :) Kevin's solution for templates was great (although something like that will probably wont apply here) kid is the best but if you need something that kid can't get you (like create plaintext, you can easy get support for it.)
I believe that on the backend in the future the best of breed will be SQLAlchemy, not SQLAlchemy with ActiveMapper.
So Turbogears code should use pure sa, while programs build on top of it can either use ActiveMapper or plain sa.
ActiveMapper should be look as a tool to make TG easier not as a core component.
and of course our docs will show how to use ActiveMapper extensively (all intro tutorials should use it), and then have a section of docs related to using pure sa.
Kevin Dangoor
> I agree 100% although i'll prefer hard to start but flexible then
> easy at start and then having to work around it.
>
I think you're missing some of the point, though... there's no
"working around" to do, per se. You could almost look at ActiveMapper
as an alternative syntax for defining Tables, that also happens to
give you objects that let you work directly with the database. If you
ever need to create your own Mappers you can... like Jonathan said,
you can get the Table object straight out of the ActiveMapper...
Kevin
Jorge Vargas
that was a generic statement, and it was more in line of ActiveMapper eventully growing bigger and becomming required instead of optional.
Kevin
Charles Duffy
> One of the patches we have for SQLAlchemy 0.2 support in TG switches
> from using ActiveMapper for the identity classes to using the straight
> SQLAlchemy model. The argument that I can see for making that change
> is that ActiveMapper is an "extension", so it's not quite as supported
> as the standard data mapper approach. The disadvantage is that it's
> more verbose and may not be as easy to grok for new users.
>
> What opinions do you all have?
Making hard things possible is important, and the reason I've decided
to use SQLAlchemy over SQLObject -- but that doesn't mean one should
sacrifice making easy things easy, which is what ActiveMapper is good
for.
Granted, I've had to run the SVN build of SQLAlchemy to get
ActiveMapper-based Identity to work with SA 0.2 (I took the 0.2-support
patch out of the relevant bug and then manually reversed the switch
away from ActiveMapper)... but that done, it *does* work, and it gives
a good template off of which to get started building my own model. Part
of providing an easy ramp-up for beginners is making working examples
easily accessible, and having the Identity classes use ActiveMapper
does that.
And as other folks have said -- the only way to get the bugs out (and,
as has been more the case for me, the only way to find and document the
places where a new user can make mistakes) is to use it.
Arnar Birgisson
> "working around" to do, per se. You could almost look at ActiveMapper
> as an alternative syntax for defining Tables, that also happens to
> give you objects that let you work directly with the database. If you
> ever need to create your own Mappers you can... like Jonathan said,
> you can get the Table object straight out of the ActiveMapper...
I think this is not a big issue. Just use either one ("plain" vs.
"activemapper") in the generated model and provide an example in the
docs on how to replace the default identity-classes with the other
kind.
My preference would be "plain" by default, ActiveMapper examples in
the docs - but that could put off potential new users.
For visit-tracking (savisit) I'm guessing very few need to customize
that part so use "plain" SA there, there's no need for the
ActiveMapper dependency.
You could also use activemapper by default, and add a parameter
"--without-activemapper" to quickstart to generate a activemapper-free
model. But that may be pushing it. :o)
Arnar