Default DB layer -- Elixir vs SA? -- Was: is there a tg 2 that's usable yet

[Mark Ramm]

> I can understand why you want to use Elixir for its ease of use but it
> bothers me when the defaults encourage bad design practices.

I don't think the Active Record pattern is a bad design practice for
*all* applications, only for ones where there are significant
divergence between the the "database design details" and the preferred
"business objects." On a photo sharing site, or a blog, or a wiki,
or any number of applications this is not true. However, I'm sure I'm
not alone when I say that my experience is that more often than not
whenever I decide "this time all my objects really do match up with my
tables, so it will be OK" I usually end up wishing I had a just a bit
more freedom to separate things.

But fortunately Elixir doesn't take over your whole model, so you're
free to manually map objects where that's a better design decision.

I do think having some of your model in Elixir and some of it in raw
SA provides a less than optimal reading experience, as the two styles
look very different. So, I do see a downside to using Elixir by
default for most all "enterprise" applications.

But, there's also somewhat more conceptual overhead, as well as more
boilerplate code to hack up a simple model with raw SA.

As I mentioned earlier my choice to use elixir as a default was mostly
designed around work being done to allow you to semi-automatically add
information about user authorization to database data. (eg, make it
easy to say that only certian people are able to edit a particular
blog post.)

But that seems like a use-case that this work may be out in the future
a bit, and it is likely of the most use to people with complex data
needs (which would also be the people who are least likely to find
Elixir's active record pattern useful).

So, this isn't an easy choice to make.

I'm very interested in hearing what the rest of the community has to
say about this.

[Neil Blakey-Milner]

On 8/14/07, Mark Ramm <mark.mch...@gmail.com> wrote:
> > I can understand why you want to use Elixir for its ease of use but it
> > bothers me when the defaults encourage bad design practices.
>
> I don't think the Active Record pattern is a bad design practice for
> *all* applications, only for ones where there are significant
> divergence between the the "database design details" and the preferred
> "business objects." On a photo sharing site, or a blog, or a wiki,
> or any number of applications this is not true. However, I'm sure I'm
> not alone when I say that my experience is that more often than not
> whenever I decide "this time all my objects really do match up with my
> tables, so it will be OK" I usually end up wishing I had a just a bit
> more freedom to separate things.

I'm four or five months (depending on how you measure) into a
3-developer "enterprise" project that uses Elixir. It's been a
learning curve for some involved, but mostly because they hadn't used
SQLAlchemy at all before, and expressing things using SQLAlchemy's SQL
generation/select/&c. was new to them.

So far, pretty smooth sailing. We've hit one "major" (to us, wouldn't
affect anyone not using database schemas) problem, and only a few
minor ones. I imagine that those who can't control their databases
will encounter more problems than we did, as well as those that have
needs that we don't (yet) - like inheritance and "associables" and so
forth, that's still being discussed in SQLAlchemy and Elixir at the
moment.

Certainly, we're doing a lot better than we would have if we'd gone
with SQLObject, and the reduced time and increased convenience of
Elixir has probably made it easier to start moving on new features.

Which is exactly what I think the default settings should do, so long
as they don't cause harm down the road by compromising design or
security.

Neil
--
Neil Blakey-Milner
http://nxsy.org/
n...@nxsy.org

[iain duncan]

> But that seems like a use-case that this work may be out in the future
> a bit, and it is likely of the most use to people with complex data
> needs (which would also be the people who are least likely to find
> Elixir's active record pattern useful).
>
> So, this isn't an easy choice to make.
>
> I'm very interested in hearing what the rest of the community has to
> say about this.

I have not used Elixer much yet, but one advantage I do see is that it
gives us a chance to insulate new users against the upcoming API changes
in SA, which will make reading the docs and learning TG a lot more
pleasant. With the upcoming SA changes, sa controller code is going to
start looking very different from SO correct?

Iain

[Dejan Rodiger]

Hi all,

I don't know the details about Elixir and SA, but my question about the
support for the "enterprise" would be:
- How do you handle upgrades of the application and database with SA/Elixir?

Do you need to create sql scripts to handle changes in the database by
hand or is this handled by Elixir/SA?
Or you need to create code that will handle that changes in the
database? And what about if you need to change some data/records in DB
during the upgrade?

Thanks

Dejan Rodiger
PGP ID 0xAC8722DC

[Mark Ramm]

This will be handled by a migration library for SQLALchemy, that will
track changes, and allow you to write python code for DB updates. It
will also help manage applying the right upgrades in the right
order...

--Mark

--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

[Paul Johnston]

Hi,

>I don't think the Active Record pattern is a bad design practice for
>*all* applications, only for ones where there are significant
>divergence between the the "database design details" and the preferred
>
>

Likewise, I think ActiveRecord is appropriate for most web apps.

I do have concerns about Elixir, because it's very different in style to
SQLAlchemy. In many ways I liked ActiveMapper better, as it was a
thinner layer, and it seemed more natural to mix ActiveMapper with plain
SA mappers. But right now Elixir is the only actively-maintained Active
Record layer for SA.

In principle I think we need the following:

The core of TG (i.e. config and request transaction wrapping) works as
long as you use SessionContext (so assignmapper, ActiveMapper, Elixir
all just work). (and in fact the config bit doesn't even need
SessionContext).
QuickStart model.py needs both a plain SA-ORM (possibly assignmapper)
mode, and an Elixir mode
Most of identity works with SA-ORM (so Elixir, etc. just work); the
quickstart bit has two modes.
FastData/CatWalk works with SA-ORM, so Elixir etc. just work.

In fact, we've already got a lot of that. But this doesn't answer the
basic question: what should the default be? Another way to put this is:
how would we like the Wiki20 tutorial to show people to do things? My
vote is for Elixir.

Paul

[Mark Ramm]

nk we need the following:
>
> The core of TG (i.e. config and request transaction wrapping) works as
> long as you use SessionContext (so assignmapper, ActiveMapper, Elixir
> all just work). (and in fact the config bit doesn't even need
> SessionContext).

Yea, but SessionContext is being replaced in SA 0.4 so we ought to use
the new scoped_session() function instead:

http://www.sqlalchemy.org/trac/wiki/WhatsNewIn04#Sessions

> QuickStart model.py needs both a plain SA-ORM (possibly assignmapper)
> mode, and an Elixir mode
> Most of identity works with SA-ORM (so Elixir, etc. just work); the
> quickstart bit has two modes.
> FastData/CatWalk works with SA-ORM, so Elixir etc. just work.

Agreed, but I think Catwalk should be replaced by something a bit more
flexible, and made usable in an actual application. I believe some
work has been done on this, and hopefully it will be very cool. But
it will be a add on feature, and shouldn't hold up the TG2 release

--Mark Ramm