It is different.
As far as I understand, in rails you create migration file and you
specify how tables have to change to go from A to B, from B to C, etc.
Each step is a migration.
In web2py you do not need to write those migration files. web2py just
compares the previous table definitions with the current one and
eventually creates or alters the tables. This has pros and cons. The
pros is that it much simpler and you do not even have to think about
it. First of all you do not have files that describe the history of
what happened other than the sql.log file. It is fine 99.9% of the
times but once in a while it fails. It may fail because you change the
type of a field from X to Y and web2py does not know who to convert
the values from X to Y. In this case you have to write a script to do
it. This kind of failure is usually very easy to recover from except
if you use MySQL. MySQL does not allow multiple ALTER tables in the
same transaction hence it can get into an odd state where some tables
have been altered and some have not. You can still recover but you may
need some info about what happens under the hood.
About web2py and Django. web2py was very much inspired by Django. The
original idea was to make web2py work as close as possible to Django
but adopt the Rails philosophy of convection over configuration in
order to make code simpler. We also added better FORM generation and
better helpers.
The Django ORM handles many 2 many relations automatically. The web2py
DAL does not. It does JOINS but it was a design choice not to abstract
too much the underlying database. That allowed us to port the DAL to
GAE. It is a philosophical difference but it can be seen as a
shortcoming of web2py by some.
Massimo
On Jul 7, 5:42 pm, eric cs <eeri...@gmail.com> wrote:
> Hey Yarko, about migrations with big apps.
> How things are done with Rails apps, then?
> Is Rails make possible to work with migration with big apps and
> upgrade, how is
> this diferent from we2py?
>
> Thanks.
>
> On Jul 7, 6:30 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
>
> > On Tue, Jul 7, 2009 at 4:53 PM, Fran <francisb...@googlemail.com> wrote:
>
> > > On Jul 7, 10:36 pm, eric cs <eeri...@gmail.com> wrote:
> > > > I'm just wondering to do big e-commerce sites like
> > > >www.taget.comorwww.bestbuy.comisn'tweb2py enough, or does it need
> > > more maturity?
> > > I imagine that a serious site like this would have a team behind it
> > > which may mean you wouldn't get all the benefits of Web2Py:
> > > * DB folks may not let you do live migrations
>
> > and you wouldn't want live migrations either - you would want to turn them
> > off after development, only use them on a "staged" next version site... you
> > would want careful deployment, different than for PyCon or other, smaller
> > traffic things....
>
> > But you would still have the web2py benefits, in the appropriate part of the
> > stage for that environment!
>
> > > * Web designers will need the full custom forms so will quickly move
> > > beyond the rapid prototyping benefits of simple {{=form}}
>
> > For something this large, this special you would want to overload, make your
> > own SQLForm, and support... and then you would have the same rapid
> > prototyping benefits, in your own preferred style... and the basics (not
> > extended) would still be available... the best of both worlds is possible
> > --- but _you_ always have to do _your_ customization; once you did, you'd
> > have the same "ease", if you intentionally wanted to keep this ease, and
> > planned on that up front.
>
> > > * You'll have rigorous change control on upgrades to framework so
> > > won't benefit from rapid codebase development
>
> > This is just nonsense - Follow anything big: Google Android development;
> > Google Chrome development (buildbot, changes are head-spinning!); Mozilla
> > Firefox build processes; etc. etc.
>
> > You would (as with Chrome, for example, which takes many open inputs - e.g.
> > Webkit; as does Android, from many, many source, linux not the least) simply
> > stage the development and incorporation of external changes, just like
> > anyone else does.
>
> > > Note this isn't a reason against Web2Py for such an application...just
> > > that it's less of a sweet spot for this framework.
>
> > There are no reasons against web2py here, other than it's being newer (e.g.
> > having seen less live traffic than something else), and the size of it's
> > developer community (which is growing, but nevertheless a consideration).
>
> > But it's less "framework" knowledge demanding and more "just python" in so
> > many places, that finding staff, contributors is less about finding someone
> > who "knows django" or "knows web2py" and much more (I think than with other
> > frameworks) about finding someone who knows jquery, web development, and
> > knows python and basics of SQL --- Everything about web2py is about little /
> > no new knowledge. The Form and Table things people ask question about
> > frequently is not because there much to know, but becuase people expect to
> > have to plumb things themselves work around things that they simply don't
> > have to with web2py (I suppose that unlearning is a kind of learning).
>
> > > I see no reason why it would actually be a bad idea to use this
> > > framework though - I imagine that you'll still be able to prototype
> > > quickly & deliver a fully-working system just a bit later.
>
> > Someone mentioned recently a project which they planned to have done by
> > years end; I suppressed my surprise. Registration and financial aid was 3-4
> > weeks of development for Pycon (edges, and adding details added perhaps
> > another month of time, but not of programming)
>
> > The key is in understanding and appropriately partitioning out, thinking
> > thru the big picture of what you are wanting to do, so you dont find
> > yourself trapped in details - details which later you discover were
> > unnecessary...
>
> > Being cognisant and observant of that _while_ doing rapid prototyping to
> > work out details of what you really want will ensure success on a big
> > project more than anything.
>
> > > Let us know how you get on :)
>
> > > F
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
