Forum: Ruby on Rails Creatulator: Before I go and make it myself, does this exist

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Mason (Guest)
on 2006-03-08 12:57
(Received via mailing list)
Basically, on thing that annoys me to no end is that I am constantly
having to add things to my model that could just be reflected out by
the active record.  I use PortGres exclusivly, and I know that there
are ways to ask the database things like, "what is the primary key"
"what relation does this foreign key belong to" etc...

So what I am about to go and write myself is a database introspector
that will look at a database and create all the Models for every table
for me, including all the set_primary_key, all the has_many
belong_tos, and many, if not all, of the validates_blah based on the
database constraints.

This is going to be quite an undertaking, so before I go and do it,
does anyone know of something that already does this that has been
previously written?
Surendra S. (Guest)
on 2006-03-08 19:56
(Received via mailing list)
Mason <removed_email_address@domain.invalid> writes:

> Basically, on thing that annoys me to no end is that I am constantly
> having to add things to my model that could just be reflected out by
> the active record.  I use PortGres exclusivly, and I know that there
> are ways to ask the database things like, "what is the primary key"
> "what relation does this foreign key belong to" etc...

ActiveRecord extensively uses introspection. There are already methods
built
for finding out all these. For any model call the method 'Methods' and
it will
return you the list of methods. Try them and find out whether what you
need is
already there or not.

--
Surendra S.
http://ssinghi.kreeti.com, http://www.kreeti.com
Read the latest news at: http://news.kreeti.com
,----
| Great wits are sure to madness near allied,
| And thin partitions do their bounds divide.
|
|     (John Dryden, Absalom and Achitophel, 1681)
`----
Neil W. (Guest)
on 2006-03-09 17:58
Mason wrote:

> This is going to be quite an undertaking, so before I go and do it,
> does anyone know of something that already does this that has been
> previously written?

Don't bother. Forget about SQL and the database completely (well almost
completely) and switch to Rails migrations. Then you can build your
schema in Ruby and let rails do the primary key stuff in the background.

To Rails the database is just a fancy filestore that we have to use
because the filesystems haven't evolved as much as we'd like and object
databases are mostly crap. Constraints should be implemented in your
object model, and validated via your test suite. Let the database just
serve data and deal with the concurrency issue.

It's a mental paradigm shift - stop checking things in two different
places.

NeilW
Lugovoi N. (Guest)
on 2006-03-09 19:04
(Received via mailing list)
On 3/9/06, Neil W. <removed_email_address@domain.invalid> wrote:
> Mason wrote:
>
> > This is going to be quite an undertaking, so before I go and do it,
> > does anyone know of something that already does this that has been
> > previously written?
>
> Don't bother. Forget about SQL and the database completely (well almost
> completely) and switch to Rails migrations. Then you can build your
> schema in Ruby and let rails do the primary key stuff in the background.
>

OK, one my Rails app  works with legacy PostgreSQL database (also
accessed from non-Rails environments), there are views, stored
procedures, schemas, composite keys, explicitly defined foreign keys
with CASCADE/RESTRICT options, non-serial primary keys (varchars),
indexes, CHECK and DEFAULT constraints for columns; triggers;  domain
types.

 Rails migrations, with their idea of logic in application only and
"least common denominator" support for databases just can't handle all
that and aren't that useful for me, so I stick with pure SQL
incremental updates.
Lugovoi N. (Guest)
on 2006-03-09 19:14
(Received via mailing list)
On 3/8/06, Mason <removed_email_address@domain.invalid> wrote:
> So what I am about to go and write myself is a database introspector
> that will look at a database and create all the Models for every table
> for me, including all the set_primary_key, all the has_many
> belong_tos, and many, if not all, of the validates_blah based on the
> database constraints.
>

Regarding associations, yes, it is possible to generate models
automatically with set_primary_key, has_many and has_one declarations,
but I suspect that manual tweaking still will be needed, e.g. when you
want to change name of the association, or use class names that don't
correspond literally to names of database tables.

And what about refreshing so generated models? Schema namespace support?

And about validations:  it is possible to define one universal
validate_against_db_constraints method, that would check all CHECK and
FOREIGN KEY constraint using single query to database and providing
rich feedback - what constraints are broken and which columns break
them :)
This topic is locked and can not be replied to.