To SQLAlchemy or ROR Active record
glenn
last paying gig, I got voted down and we are doing it with ruby on
rails. Now another opportunity arises and I have to evaluate what our
options are again.
I've only used SQLObject, with in out side of TG, having got used ROR
active record however it feels a little cumbersome. There are 2
characteristics of active record, that may loose this debate for me
when the time comes.
1) I don't have to define (and maintain) field definitions in the
model - they are 'inferred' and appropriate accessor methods provided
at run time. Glancing at SA, i notice there is opportunity to write
models, and so generate the schema (like SO), but is there also
facility just to 'attach' to a schema and have (validation ,
associations (relationships) and biz rules aside) a working model?
2) ActiveMigration makes it clean and simple without being magic, to
move up and down between schema versions. So, regardless of answer in
1, does SA address this in someway? either by providing clean
schema/model deltas, or a simple (db engine independent) way to write
and impliment them?
Thanks
glenn
isaac
http://www.sqlalchemy.org/docs/plugins.myt#plugins_activemapper
and...
http://turboentity.ematia.de/index.html
HTH
Karl Guertin
> 1) I don't have to define (and maintain) field definitions in the
> model - they are 'inferred' and appropriate accessor methods provided
> at run time. Glancing at SA, i notice there is opportunity to write
> models, and so generate the schema (like SO), but is there also
> facility just to 'attach' to a schema and have (validation ,
> associations (relationships) and biz rules aside) a working model?
You can do this with the previously mentioned extensions, but the
authors of those two extensions are collaborating on a new active
record style mapper. I prefer explicitly writing the table definitions
out. It takes an extra 10 minutes for most projects. The only thing I
dislike about it is that your table definitions are in three places. A
code folding editor works, but it's still annoying.
In both SA and SO you can automatically infer a model from an existing
database. The legacy databases I've dealt with tend to be too sloppy
for this to work well.
> 2) ActiveMigration makes it clean and simple without being magic, to
> move up and down between schema versions. So, regardless of answer in
> 1, does SA address this in someway? either by providing clean
> schema/model deltas, or a simple (db engine independent) way to write
> and impliment them?
http://erosson.com/migrate/docs/
Haven't tried it, keep meaning to.
Lee McFadden
>
> You can do this with the previously mentioned extensions, but the
> authors of those two extensions are collaborating on a new active
> record style mapper. I prefer explicitly writing the table definitions
> out. It takes an extra 10 minutes for most projects. The only thing I
> dislike about it is that your table definitions are in three places. A
> code folding editor works, but it's still annoying.
>
My tip for this cuts it down to two places, the table and object and
the mappers.
I just create my table and then defind the ORM object directly after that table.
foo_table = Table("foo", metadata,
Column("id", Integer, primary_key=True),
Column("bar", Unicode),
)
class Foo(object):
pass
Then all my mappers are at the end of my model.py so they're all kept
in the same place... it makes it easier to find your object and table
and there's no reason why they need to be separated.
Lee
--
Lee McFadden
blog: http://www.splee.co.uk
work: http://fireflisystems.com
Marco Mariani
> In both SA and SO you can automatically infer a model from an existing
> database. The legacy databases I've dealt with tend to be too sloppy
> for this to work well.
>
dictionary is not helping me
I am a happy user of the autoload feature, as I think it's a good way to
pay respect to the role of a DBMS. Likewise, I am no fan (well... not
anymore) of the automagically generated validation rules and CRUD forms.
I hate writing repetitive code as much as the next guy, but for my use
cases (relatively few forms but stra^H^H^H^Hinteresting business rules)
I cannot see the shortcomings of my approach... not yet, at least.
I used autoload to support a legacy schema, but if I had to start a new
application now, with no legacy database, I'm sure I would keep schema
definition in postgres. I've read somewhere that Michael does not really
like it, and I'm fine with that, but I hope autoload will never be a
child of a lesser SQLAlchemy :-)
Did anybody regret going with autoload=True? Why?
Karl Guertin
> Uh. I am no native english speaker, please define sloppy.. the
> dictionary is not helping me
Sloppy is the opposite of precise. A proper database is normalized,
has explicit foreign keys, explicit constraints on columns, etc. Many
of the databases I've mapped do not have these, so autoload=True
doesn't pick them up and I have to define the tables to get everything
working smoothly.
Glenn Davy
On Tue, 2006-11-21 at 11:00 -0500, Karl Guertin wrote:
> On 11/21/06, glenn <gl...@tangelosoftware.net> wrote:
> > 1) I don't have to define (and maintain) field definitions in the
> > model - they are 'inferred' and appropriate accessor methods provided
> > at run time. Glancing at SA, i notice there is opportunity to write
> > models, and so generate the schema (like SO), but is there also
> > facility just to 'attach' to a schema and have (validation ,
> > associations (relationships) and biz rules aside) a working model?
>
> You can do this with the previously mentioned extensions, but the
> authors of those two extensions are collaborating on a new active
> record style mapper. I prefer explicitly writing the table definitions
> out. It takes an extra 10 minutes for most projects. The only thing I
> dislike about it is that your table definitions are in three places. A
> code folding editor works, but it's still annoying.
>
> In both SA and SO you can automatically infer a model from an existing
> database. The legacy databases I've dealt with tend to be too sloppy
> for this to work well.
>
capacity to infer a model - it isnt dynamic and still needs to be kept,
on a column by column basis in a python model definition. Meaning that
as the schema evolves this model has to be maintained. Is that correct
or am I missing something?
> > 2) ActiveMigration makes it clean and simple without being magic, to
> > move up and down between schema versions. So, regardless of answer in
> > 1, does SA address this in someway? either by providing clean
> > schema/model deltas, or a simple (db engine independent) way to write
> > and impliment them?
>
> http://erosson.com/migrate/docs/
>
> Haven't tried it, keep meaning to.
yeah know what thats about - theres just too many things out there to
have your head around and spend time 'trying' instead of producing
>
thanks all
Glenn
> >
Jorge Godoy
> In both SA and SO you can automatically infer a model from an existing
> database. The legacy databases I've dealt with tend to be too sloppy
> for this to work well.
Looking from another side, mapping views and tables again is a lot boring when
you have your ER model as the official documentation or when your project is
not the only one to use the database.
Of course, for small projects this isn't important because most of them will
be the sole "users" of the database, but when you have to integrate with
reporting tools, office suites, GUI, web apps, etc. you start thinking
different.
But I agree that being able to control how these structures map into Python is
a huge advantage (and what makes me do the redundant work...).
--
Jorge Godoy <jgo...@gmail.com>
Jorge Godoy
> Many of the databases I've mapped do not have these, so autoload=True
> doesn't pick them up and I have to define the tables to get everything
> working smoothly.
This is more common for old web apps written in a certain language that has 3
letters and the middle one is 'H'... ;-) But I also see a lot of these.
Fixing them is a hell lot of work.
Today I was evaluating if I should go and fix an old application for a client
of mine or if I should tell them that the guy that wrote it was so crazy that
there's no way to fix it. Lots of redundant and spread code mixed with HTML
and JavaScript and ... that it will probably take me longer to find out how
things are connected than writing a new app with TG...
--
Jorge Godoy <jgo...@gmail.com>
Glenn Davy
What did you decide to tell them?
I've just spent a couple of days a week for 12 mths in a similar
situation (even worse - using asp ) - just handed in notice as there is
no commitment on their part to allow change. After 12 mths we only
think we know how it works.
Glenn Davy
'being able map these into python' to is a huge advantage, do you mean
is a huge advantage over having that mapping done automatically? or
something else? Do you consider its disadvantage having to (vs being
able to) explicitly declare the mapping?
thanks
Glenn
>
Jorge Godoy
> What did you decide to tell them?
For now that some parts can be touched and toyed with until they get to do
something near what they want, some other parts are like a huge rock on the
head of a needle and should never be touched and finally that developing new
features using this model will be slow and fragile... VERY fragile.
But I also told them that I'd talk to some developers more experienced with
PHP (ARGH!) and see what they think of it. I'm used to cleaner code and also
with comments on the code. I believe that if this program has 10/12 lines of
comments for every 2K lines of code it will be too much.
Not to mention JavaScript that implements multi-browser support by hand and
glueing libs from 2002 with libraries from 2003 with ugly code of their own
from 2005 (think about multi-browser support on these years and how it
changed...)... There's nothing like Dojo, MochiKit or any other toolkit to
make it easier to deal with the code... All is a mess. Some code in pt_BR,
some in en_US, some in it_IT... A lot of cut & paste.
> I've just spent a couple of days a week for 12 mths in a similar situation
> (even worse - using asp ) - just handed in notice as there is no commitment
> on their part to allow change. After 12 mths we only think we know how it
> works.
I prefer declaring the project "impossible". It is cheaper to me and to my
client. I'll have to write something like this application to a huge project
of mine, so I might end up offering it for them -- billing the same code
twice, at least, since it will be for two different clientes ;-) -- and it
will be cheaper and faster than spending more time to fix it.
As they're also developers, it is easier to show the code and how bad it
is...
--
Jorge Godoy <jgo...@gmail.com>
Lee McFadden
>
--8<-- snip --8<--
> Do you consider its disadvantage having to (vs being
> able to) explicitly declare the mapping?
>
Personally, I consider it an *advantage* to explicitly declare the
mappings when the database is either from a legacy app or is part of a
larger system. I've had to develop apps for both circumstances and I
started by using table reflection in SO and later in SA. While SA
does a stirling job and SO a slightly less stirling job (although it's
still good) of getting the models right, there's only so much they can
do if a DB isn't quite declared properly.
You may spend days/weeks tracking down a bug, especially in a complex
system, that can be attributed to the table reflections not being
*quite* how you expected them.
It's better, IMHO, to spend the extra time explicitly mapping the
database so you *know* exactly how it's going to act even if the table
definitions aren't quite 100% as they're supposed to be. Believe me,
it's going to save you time in the long run.
Jorge Godoy
> Can I ask what your take on the ROR activeRecord model is? When you say
I haven't used RoR enough to have an opinion for the kind of project I was
thinking. Sorry... I can't answer that.
> 'being able map these into python' to is a huge advantage, do you mean
> is a huge advantage over having that mapping done automatically? or
I mean that being able to define the structures and their particularities by
hand is an advantage over having to accept just what is on the database. For
some legacy applications one might not be able to implement new features on
the database and being able to create them on your ORM is very nice. Also,
being able to enforce some naming conventions for your project and having
those different from the naming convention from your DBAs ensures consistency
for both worlds.
> something else? Do you consider its disadvantage having to (vs being
> able to) explicitly declare the mapping?
I consider that we have the best thing since we don't have an XOR but we can
do both things and even mix them. :-) You're not restricted to either do it
all by hand or do it all automatically: you can have some tables automatically
inferred from the database and other manually specified on the same model.
I use it for views here: some of them are created automatically with whatever
is defined on the database, some other are manually created. I have opted to
specify all my tables by hand, but I have lots of maintenance SQL scripts to
migrate the database and/or make use of more advanced features from the
database.
I'm one of the people that believe that the database has to have some
intelligence and shouldn't be handled just like a bag of data ;-) (But this
is a different "war" on the RDBMSs world.)
--
Jorge Godoy <jgo...@gmail.com>
Glenn Davy
legacy system. I guess my concern, or more accuratley what Im actually
trying to establish, is whether or not there is the option of not
_having_ to (as per active record and IRC dabo's bizobject) to that, esp
on a crisp shiny new schema.
Glenn Davy
> Glenn Davy <gl...@tangelosoftware.net> writes:
>
> > Can I ask what your take on the ROR activeRecord model is? When you say
>
> I haven't used RoR enough to have an opinion for the kind of project I was
> thinking. Sorry... I can't answer that.
>
> > 'being able map these into python' to is a huge advantage, do you mean
> > is a huge advantage over having that mapping done automatically? or
>
> I mean that being able to define the structures and their particularities by
> hand is an advantage over having to accept just what is on the database. For
> some legacy applications one might not be able to implement new features on
> the database and being able to create them on your ORM is very nice. Also,
> being able to enforce some naming conventions for your project and having
> those different from the naming convention from your DBAs ensures consistency
> for both worlds.
>
> > something else? Do you consider its disadvantage having to (vs being
> > able to) explicitly declare the mapping?
>
> I consider that we have the best thing since we don't have an XOR but we can
> do both things and even mix them. :-) You're not restricted to either do it
> all by hand or do it all automatically: you can have some tables automatically
> inferred from the database and other manually specified on the same model.
>
database - that is to say that:
a) a model is 'written', albeit automagically, into python?
- VS -
b) no declarative, coded model being necessary (except for validation,
bizrules and relationships) whether written by magic, or hand - instead
just inferred and added to instance at run time?
> I use it for views here: some of them are created automatically with whatever
> is defined on the database, some other are manually created. I have opted to
> specify all my tables by hand, but I have lots of maintenance SQL scripts to
> migrate the database and/or make use of more advanced features from the
> database.
>
> I'm one of the people that believe that the database has to have some
> intelligence and shouldn't be handled just like a bag of data ;-) (But this
> is a different "war" on the RDBMSs world.)
Ah yes... I tend to come down on your side of the fence in this fight,
at least in most real world cases. In many scenarios Id prefer to
sacrifice the ability to 'switch' to another back end, and have biz
logic in database, where anyone can write a ui for it anyway they want
and get consistant behaviour - rather than commit everyone to some
arbitary programing environment that may change on a whim. At least when
circumstances dont allow for a more full blown 3tier arrangement. Its a
fight i have to have over and over again, but its paid its dividends
time after time.
>
>
Jorge Godoy
> can I just clarify... when you say sometables are inferred from the
> database - that is to say that:
> a) a model is 'written', albeit automagically, into python?
> - VS -
> b) no declarative, coded model being necessary (except for validation,
> bizrules and relationships) whether written by magic, or hand - instead
> just inferred and added to instance at run time?
The model isn't written anywhere and you have a "fromDatabase = True"
instruction so that the ORM learns what it needs from the existing database.
> Ah yes... I tend to come down on your side of the fence in this fight,
> at least in most real world cases. In many scenarios Id prefer to
> sacrifice the ability to 'switch' to another back end, and have biz
> logic in database, where anyone can write a ui for it anyway they want
> and get consistant behaviour - rather than commit everyone to some
> arbitary programing environment that may change on a whim. At least when
> circumstances dont allow for a more full blown 3tier arrangement. Its a
> fight i have to have over and over again, but its paid its dividends
> time after time.
You can have database independence with language restrictions, language
independence with database restrictions. Not both, unfortunately, since the
most advanced features of databases go to a proprietary side...
A 3tier solution comes into the fight at the cost of performance (talking to a
middle layer that will talk to the database never will be as fast as talking
directly to the database).
Anyway, this is too off-topic. :-)
--
Jorge Godoy <jgo...@gmail.com>
Glenn Davy
> Glenn Davy <gl...@tangelosoftware.net> writes:
>
> > can I just clarify... when you say sometables are inferred from the
> > database - that is to say that:
> > a) a model is 'written', albeit automagically, into python?
> > - VS -
> > b) no declarative, coded model being necessary (except for validation,
> > bizrules and relationships) whether written by magic, or hand - instead
> > just inferred and added to instance at run time?
>
> The model isn't written anywhere and you have a "fromDatabase = True"
> instruction so that the ORM learns what it needs from the existing database.
>
> > Ah yes... I tend to come down on your side of the fence in this fight,
> > at least in most real world cases. In many scenarios Id prefer to
> > sacrifice the ability to 'switch' to another back end, and have biz
> > logic in database, where anyone can write a ui for it anyway they want
> > and get consistant behaviour - rather than commit everyone to some
> > arbitary programing environment that may change on a whim. At least when
> > circumstances dont allow for a more full blown 3tier arrangement. Its a
> > fight i have to have over and over again, but its paid its dividends
> > time after time.
>
> You can have database independence with language restrictions, language
> independence with database restrictions. Not both, unfortunately, since the
> most advanced features of databases go to a proprietary side...
>
> A 3tier solution comes into the fight at the cost of performance (talking to a
> middle layer that will talk to the database never will be as fast as talking
> directly to the database).
>
> Anyway, this is too off-topic. :-)
find anyone with an overlapping point of view on this, but will leave
alone as you righlty suggest
thanks for your input
Glenn
>
iain duncan
My two cents on this:
You're best friends for stuff like this are some good books on sales and
marketing. ;) Most coders don't learn how to pitch. My other job is show
biz, when learning how to pitch is massively important, and it has paid
huge dividend in getting clients to see why my solution is a good
solution for all of us.
My favourite classics:
- "How to win friends and influence people" Dale Carnegie ( every self
employed person should own a copy of this book )
- "What they don't teach you in Harvard Business School" - another old
classic for a reason
- any of the numerous sales books by Brian Tracy
The thing that's hard here is that you are simultaneously pitching them
on your plan, but also they have to accept that they made a *bad*
purchase previously, and nobody likes to feel bad about their decision.
If you can figure out how to *show them* that the most cost effective
solution in the long run for them and you is to pay you more know for a
better extensible system, then you should be able to overhaul the whole
mess and increase the budget enough that you do it with a smile.
Whenever I hear coders lamenting situations like this ( and we all know
it happens to all the time! ) my advice is,
- get a good book on sales
- figure out how to raise the budget until you can exceed their
expectations and still be happy with what you are giving them and your
time commitment
- make everyone say yes and leave happy with their purchase
I think it's better to risk losing it to pitch for a budget where you
can all do a good job and be happy with the gig.
( end rant! )
Iain
( As a famous and wealthy juggling duo I know once said, 30% of your
calls should think you are too expensive! )
>
>
Glenn Davy
too comfortable wearing. read dale carnegie when I was a kid. first and
last 'sales book' i read.
As for:the rest - I cant agree more - My qualitiy of life went way up
when I accepted the truth of that statement
> I think it's better to risk losing it to pitch for a budget where you
> can all do a good job and be happy with the gig.
> ( As a famous and wealthy juggling duo I know once said, 30% of your
iain duncan
> Upto this point - i prob have to conceed you're right, but not a hat im
> too comfortable wearing. read dale carnegie when I was a kid. first and
> last 'sales book' i read.
keep in mind there's a real difference between pressure sales and good
negotiation. In our industry, we want good negotiation, because we want
them to be happy and come back for more ( just as with my shows ). This
makes for a totally different sales dynamic from say, car selling, where
someone needs to be "closed" and after that, who cares? They won't buy
another car for ages. So, IMHO, an awful lot of good sales practise that
would benefit people like us goes unlearnt or ignored because the word
"Sales" is associated with pressure sales. And that's the last thing you
want to use in web dev. But you *do* need to learn about the psychology
of purchasing decisions because you are constantly having to *show*
people why your proposal is a good one. If it is indeed a good deal for
everyone, then nobody is losing and good sales practise is warranted and
ethical.
Anyhoo, ot, but hopefully useful to somebody.;)
Iain