Hi,
Apologies for missing the discussion on the decision to remove
implicit transactions and sessions from 1.1 (if there was one... I
can't find it in the archives). One of the things that I think makes
TG great is the existence of automatic transactions. I understand the
requirement to turn off transactions at the controller level (or the
project level), but removing them entirely seems to me to be a giant
step backward. It's extremely useful to know that an exception-
raising controller doesn't (by default) leave the database in an
inconsistent state. This allows the controller code to be more
straightforward, knowing that the framework will "do the right thing"
in the case of an exception.
As for sessions, again, this seems like something that really belongs
in the framework, if we want to claim to "integrate" with an ORM. A
session is an absolute requirement for every controller that uses the
ORM layer of SA at all, so why not make it available? I know that SA
gives you the ability to work at the SQL layer (and thus not need a
session), but I know that, at least in my case, the vast majority of
controllers need one.
Essentially, we're taking this:
@expose('project.templates.page')
@validate(validators=dict(obj_id=Integer(not_empty=True)))
def do_something(self, obj_id):
obj = session.query(SomeClass).get(obj_id)
obj.method(...)
return dict(...)
and making it this:
@expose('project.templates.page')
@validate(validators=dict(obj_id=Integer(not_empty=True)))
def do_something(self, obj_id):
try:
session = Session() # or create_session
obj = SomeClass.get(obj_id)
obj.method(...)
session.commit()
return dict(...)
except (HTTPRedirect, InternalRedirect), exc:
session.commit()
raise
except:
session.rollback()
raise
So that's 9 extra lines of boilerplate for every controller, OR I
write a decorator that (IMO) does what the framework should be doing
in the first place. (Plus I haven't even handled transactions for the
SQL layer stuff....)
Just my $.02
On Oct 11, 3:59 am, "Florent Aide" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> as promised here is the todo list I identify has a "must do" for the
> 1.1 release:
>
> - finish SA 0.4 port by removing all ActiveMapper and make sure all
> tests pass again
> - remove implicit transactions from the core
> - make plain SA the default template for the model and move Elixir
> templates in a plugin
> - fix the various templates to use the new session systems (sa
> sessions will need to be created in the controller) and add some
> examples of transactions
> - Fix all failing tests and add new ones.
> - Document the API by adding all the missing docstrings.
> - break the config system out of the CP config by creating our own
> config layer that must instrument CP's config without being
> intertwined as it is right now.
>
> Big Bonus:
> document ToscaWidgets and then remove TG widgets from the core to use
> only Tosca.
>
> Medium Bonus:
> Provide transaction management giving the same kind of functionality
> as we have today but outside of the core (has a plugin, one plugin for
> each orm). Mark suggests using either decorators or subclassing the tg
> controller and after discussion a decorator I agree with him on the
> decorator :)
>
> For the SA part + transactions, I'll commit some preliminary work in
> the 1.1 branch later on this week (I have a roughly working version on
> my machine)
> For the config part I am still thinking about it and would welcome
> suggestions.
>
> More on this later, Cheers...
>
> Florent.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
