Just seen on c.l.py

[Stephen Kellett]

Hi Folks,

Just browsing c.l.py and found this advertised as a Rails killer... hmmm
not very friendly.

http://www.djangoproject.com/

Make of it what you will.

Stephen

 

[gabriele renzi]

Stephen Kellett ha scritto:

Hi Folks,

Just browsing c.l.py and found this advertised as a Rails killer... hmmm
not very friendly.

http://www.djangoproject.com/

I thought Django just used to kill bandits and evil overlords! [1]


[1]
http://www.dvdmaniacs.net/Reviews/Q-T/spaghetti_western_set.html

 

[Vincent Foley]

It's Django Fett, beware!

Seriously, I don't think a good full-stack web-development framework
for Python is a bad thing. Sure, some people may decide to use it
instead of Rails, but what are you gonna do about that? We can see
what they did right and try to bring that to Rails. I think one of
most important things to eventually get into Rails is being able to use
an already-existing database. I don't know, maybe with a YAML file, a
legacy.rb file, whatever. I don't know if django has that, but if they
do, it might be a good thing t investigate it.

Vincent.

 

[James Britt]

Hi Folks,

Just browsing c.l.py and found this advertised as a Rails killer... hmmm
not very friendly.

http://www.djangoproject.com/

Make of it what you will.

See the thread on the Rails dev list about Django.

James

 

[Nicholas Van Weerdenburg]

Stephen Kellett ha scritto:

Hi Folks,

Just browsing c.l.py and found this advertised as a Rails killer... hmm= m
not very friendly.

http://www.djangoproject.com/

=20
I thought Django just used to kill bandits and evil overlords! [1]
=20
=20
[1]
http://www.dvdmaniacs.net/Reviews/Q-T/spaghetti_western_set.html
=20
=20

Django Reinhart, my favorite Jazz artist-

http://www.djangomontreal.com/doc/DjangoStory.htm

Nick
--=20
Nicholas Van Weerdenburg

 

[Phil Tomson]

Hi Folks,

Just browsing c.l.py and found this advertised as a Rails killer... hmmm
not very friendly.

http://www.djangoproject.com/

Make of it what you will.

I'm not much of a web programmer nor have I done any SQL so when I went
through Curt Hibb's Rails tutorial I kept thinking "why do I have to mess
with this SQL stuff? Why can't I describe the data/tables in Ruby and
then have Rails take care of all that stuff for me" (it seemed somehow like
the DRY principle was being violated).

So the first thing I notice about Django just now was:

"Design your model
Start by describing your database layout in Python code. Django's
data-model API offers many rich ways of representing your models -- ...

Install it
Next, run the Django command-line utility. It'll create the database
tables for you automatically, in the database specified in your Django
settings."

This seems appealing. Is there a way of doing this in Rails?

Phil

 

[gabriele renzi]

Phil Tomson ha scritto:

This seems appealing. Is there a way of doing this in Rails?

AFAIK this cannot be done with rails' ActiveRecord but it should be
possible to do it with Og, the object/relational bridge in nitro.
And you should be able to mix & match pieces from nitro and rails (and
wee). Cool ain't it?

 

[James Britt]

I'm not much of a web programmer nor have I done any SQL so when I went
through Curt Hibb's Rails tutorial I kept thinking "why do I have to mess
with this SQL stuff? Why can't I describe the data/tables in Ruby and
then have Rails take care of all that stuff for me" (it seemed somehow like
the DRY principle was being violated).

This is how Nitro works. The class definitions drive the tables, not
the other way around.

www.nitrohq.com


James


--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[Joe Van Dyk]

It's Django Fett, beware!
=20
Seriously, I don't think a good full-stack web-development framework
for Python is a bad thing. Sure, some people may decide to use it
instead of Rails, but what are you gonna do about that? We can see
what they did right and try to bring that to Rails. I think one of
most important things to eventually get into Rails is being able to use
an already-existing database. I don't know, maybe with a YAML file, a
legacy.rb file, whatever. I don't know if django has that, but if they
do, it might be a good thing t investigate it.

Rails can use existing databases just fine. You lose some of the
magic stuff, but most of it works fine, AFAIK.

 

[Joe Van Dyk]

=20
This is how Nitro works. The class definitions drive the tables, not
the other way around.
=20
www.nitrohq.com
=20
=20

If you use Migrations (introduced very recently with Rails), you can
specify the database structure in Rails. All that's needed is for you
to create the database.

 

[James Britt]

If you use Migrations (introduced very recently with Rails), you can
specify the database structure in Rails. All that's needed is for you
to create the database.

Oh, so as I develop my application and change my objects, the database
changes along with it? Interesting.

James



--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[Lothar Scholz]

Hello James,


JB> Oh, so as I develop my application and change my objects, the database
JB> changes along with it? Interesting.

Normally yes.

This is done once after a restart of the server - at least in the frameworks
i know. But of course this only works with application server
frameworks and databases which have an 'alter table' (so not with
Sybase or MSSQL Server)

 

[James Britt]

Hello James,

JB> Joe Van Dyk wrote:




JB> Oh, so as I develop my application and change my objects, the database
JB> changes along with it? Interesting.

Normally yes.

This is done once after a restart of the server - at least in the frameworks
i know. But of course this only works with application server
frameworks and databases which have an 'alter table' (so not with
Sybase or MSSQL Server)

Are you talking about what Rails does, or about how some framework in
general might do this? The comment from Joe Van Dyk suggests that now,
in Rails, you can evolve your object model and the database will
automagically change with it; no more need to "code" in SQL.


James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[David Heinemeier Hansson]

Are you talking about what Rails does, or about how some framework in

general might do this? The comment from Joe Van Dyk suggests that now,
in Rails, you can evolve your object model and the database will
automagically change with it; no more need to "code" in SQL.

Exactly. Migrations were originally intended to solve the problem of
evolving a database schema across multiple databases with as little
pain as possible and without loosing your data. Especially the last
bit is where most Object->SQL auto-generation schemes fall down.

But it can certainly also be used to create your entire database from
scratch, so that you won't have to touch SQL at all. Example:

create_table :system_settings do |t|
t.column :name, :string
t.column :label, :string
t.column :value, :text
t.column :type, :string
t.column osition, :integer
end

It currently only works for MySQL and PostgreSQL, but we're working on
SQLite support using temporary tables, which in turn will make it
suitable for SQL Server, Sybase, and all the other databases that
aren't jiggy with ALTER TABLE.

There's more information at:
http://api.rubyonrails.org/classes/ActiveRecord/Migration.html

And there's full Rails support in form of "script/generate migration
add_system_settings" and "rake migrate".

We've been using it for quite a while with all the 37signals
applications and its such bliss to be able to treat your schema as
clay instead of rock.
--=20
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework

 

[James Britt]

Exactly.

Well, not exactly, or not really what I was thinking of. I meant one
can define a class, with whatever properties and behavior, and Rails
would determine the proper database structure from my actual class
code, not from a separate Ruby command to go create a table. But being
able to avoid running a special configuration too, (i.e, a SQL editor or
admin GUI) in order to write Ruby is a plus in any event.

An annoyance I have with Rails is that when I want to see if an object
has some particular property I have to go run an SQL app or look
someplace other than in the class definition.

The code at

http://api.rubyonrails.org/classes/ActiveRecord/Migration.html

suggests that the object/table definitions are occurring someplace other
than in the class definition itself, something I'm not quite, um,
"jiggly" with.


James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[Jamis Buck]

Well, not exactly, or not really what I was thinking of. I meant one
can define a class, with whatever properties and behavior, and Rails
would determine the proper database structure from my actual class
code, not from a separate Ruby command to go create a table. But
being able to avoid running a special configuration too, (i.e, a
SQL editor or admin GUI) in order to write Ruby is a plus in any
event.

An annoyance I have with Rails is that when I want to see if an
object has some particular property I have to go run an SQL app or
look someplace other than in the class definition.

Well, but that's just ActiveRecord, right? Not Rails as a whole. You
can use any other ORM you want with Rails, if AR doesn't fit your
style of thinking.

For me, I really like that AR doesn't clutter my model classees with
extraneous definitions. I like looking at a two or three line model
class, that only defines the behavior of the class and the foreign
key relationships. Others (like yourself, James) obviously prefer the
model to be everything, including the explicit definition of the data
itself. And that's cool.

But yah, ActiveRecord does not do the Og-thang and allow you to
define your schema in your model (at least, not so that the database
can be created from the model).

- Jamis

 

[James Britt]

Well, but that's just ActiveRecord, right? Not Rails as a whole. You
can use any other ORM you want with Rails, if AR doesn't fit your style
of thinking.

Yes, I would imagine. But then one is no longer really dealing with
Rails but with, well, some custom arrangement of libraries. Which may
be the better way to look at it anyway, even if one uses AR.

For me, I really like that AR doesn't clutter my model classees with
extraneous definitions. I like looking at a two or three line model
class, that only defines the behavior of the class and the foreign key
relationships. Others (like yourself, James) obviously prefer the model
to be everything, including the explicit definition of the data itself.
And that's cool.

Clutter? Interesting. When I'm looking to see what values I can obtain
from an object passed to a view, or what it expects passed to the
constructor when instantiated, th AR-based class code won't tell me. I
have to go look at a .sql file or open up some DB admin tool to locate
such extraneous details.

Worse, if I go change object behavior, I have to bounce back to some
other file or application to ensure I'm making changes in all the right
places. (I know this has all been discussed on the Rails list; different
strokes, and all that.)

But yah, ActiveRecord does not do the Og-thang and allow you to define
your schema in your model (at least, not so that the database can be
created from the model).

Which is basically what I was looking for. But I have to go poke around
with migrations, because it may make a few Rails things simpler.

Thanks,

James


--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[JZ]

Exactly. Migrations were originally intended to solve the problem of
evolving a database schema across multiple databases with as little
pain as possible and without loosing your data. Especially the last
bit is where most Object->SQL auto-generation schemes fall down.

But it can certainly also be used to create your entire database from
scratch, so that you won't have to touch SQL at all. Example:

create_table :system_settings do |t|
t.column :name, :string
t.column :label, :string
t.column :value, :text
t.column :type, :string
t.column osition, :integer
end

David, how would you define collations or constrains here?

 

[JZ]

David, how would you define collations or constrains here?

To be more specific... how to prepare "create_table :system_settings ..."
code for such table:

CREATE TABLE `book` (
`id` int(10) unsigned NOT NULL auto_increment,
`book_id` varchar(3) character set utf8 NOT NULL default '',
`chapter_nr` smallint(5) unsigned NOT NULL default '0',
`verse_nr` smallint(5) unsigned NOT NULL default '0',
`verse` text collate utf8_polish_ci NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `idx_uniq` (`book_id`,`chapter_nr`,`verse_nr`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

 

[George Moschovitis]

Migrations seems to follow the RY principle: define parts of the schema
in:

* sql files
* migration files
* ruby code

For example to define a 'many_to_many relation' you have to add sql
code in the sql file, and add the 'has_and_belongs_to_many' macro in
Ruby code. And if you want to support multiple backends (for example
when you want to release an open source project like Typo) you have to
repeat your self again.

BTW, when using Migrations, notice how you use a method to define
attributes for your model class, not really oop.

Og makes all this natural. Have a look at www.nitrohq.com

regards,
-g.