Hi Folks,
Just browsing c.l.py and found this advertised as a Rails killer... hmmm
not very friendly.
Make of it what you will.
Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
Stephen Kellett ha scritto:
Hi Folks,
Just browsing c.l.py and found this advertised as a Rails killer... hmmm
not very friendly.
I thought Django just used to kill bandits and evil overlords! [1]
[1]
http://www.dvdmaniacs.net/Reviews/Q-T/spaghetti_western_set.html
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.
Stephen Kellett wrote:
Hi Folks,
Just browsing c.l.py and found this advertised as a Rails killer... hmmm
not very friendly.Make of it what you will.
See the thread on the Rails dev list about Django.
James
In article <05th9VCgqN2CFwW4@objmedia.demon.co.uk>,
Hi Folks,
Just browsing c.l.py and found this advertised as a Rails killer... hmmm
not very friendly.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
Stephen Kellett <snail@objmedia.demon.co.uk> wrote:
Django Reinhart, my favorite Jazz artist-
http://www.djangomontreal.com/doc/DjangoStory.htm
Nick
On 7/16/05, gabriele renzi <surrender_it@remove-yahoo.it> wrote:
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
--
Nicholas Van Weerdenburg
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? 
Phil Tomson wrote:
In article <05th9VCgqN2CFwW4@objmedia.demon.co.uk>,
Hi Folks,
Just browsing c.l.py and found this advertised as a Rails killer... hmmm
not very friendly.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).
This is how Nitro works. The class definitions drive the tables, not the other way around.
James
Stephen Kellett <snail@objmedia.demon.co.uk> wrote:
--
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
Rails can use existing databases just fine. You lose some of the
magic stuff, but most of it works fine, AFAIK.
On 7/16/05, Vincent Foley <vfoley@gmail.com> wrote:
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.
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.
On 7/16/05, James Britt <james_b@neurogami.com> wrote:
Phil Tomson wrote:
> In article <05th9VCgqN2CFwW4@objmedia.demon.co.uk>,
> Stephen Kellett <snail@objmedia.demon.co.uk> wrote:
>
>>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).This is how Nitro works. The class definitions drive the tables, not
the other way around.
Joe Van Dyk wrote:
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
Hello James,
Joe Van Dyk wrote:
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.
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)
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
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.
Lothar Scholz wrote:
Hello James,
> Joe Van Dyk wrote:
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.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
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 :position, :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:
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.
--
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
David Heinemeier Hansson wrote:
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.
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
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
David, how would you define collations or constrains here?
On Sun, 17 Jul 2005 22:23:09 +0900, David Heinemeier Hansson wrote:
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 :position, :integer
end
--
JZ
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
On Jul 17, 2005, at 7:56 AM, James Britt wrote:
David Heinemeier Hansson wrote:
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.
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.
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;
On Sun, 17 Jul 2005 23:35:21 +0200, JZ wrote:
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 :position, :integer
endDavid, how would you define collations or constrains here?
--
JZ
Jamis Buck wrote:
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