Modifying MetaRails apps

[Piotr Kopszak]

Hello Group!

I am using MetaRails to set up new apps and administer it initially
thanks to its ActiveRecord based interface but I was wondering if it
is possible to modify it using its yaml definition files.Now I'm using
migrations and modify models and controllers by hand. I guess the
definition files could be versioned like migrations in that case.
It's not hard to add new models to MetaRails or modify existing ones
so I guess it should not be too difficult.

Piotr

[Sergio Espeja]

Hello Piotr!

Currently metarails can make modifications to the database using migrations but don't modify the rails models. Make changes to the database with migrations are so easy because you only have to add the changes in new migration files, but change the models is a little bit more difficult because you can overwrite custom code...

MetaRails plans to implement this functionality, the first aproach will be to change the code between:
# Code generated by MetaScaffold BEGIN
...
# Code generated by MetaScaffold END

Any other ideas?
Sergio

[Jorge L. Cangas]

This is a point that alwais was unclear for me: why we need the .yaml files at first?? I see that like duplicating the content of migrations files a bit. Maybe I missed some point, of course, but I think is better to refactor meta-rails in order to don't use this yaml files ... :)

2008/1/22, Sergio Espeja <sergio...@gmail.com>:

[Sergio Espeja]

Hi Jorge,

The idea of using the .yml files is to DRY when you define a model and a migration for some class. For example: A class has a belongs_to relation with another class, without MetaScaffold (MetaRails plugin) you must write in the migration " t.column :example_id, :integer" and in the model "belongs_to :example", with MetaScaffold you only have to write "belongs_to :example".

It's more DRY, don't?
Sergio

[Jorge L. Cangas]

Yes and not :). Yes because don't need the belongs_to in the model. Not because we are duplicating things in migration file and the yaml file. The need of adding belongs_to to de the model is a bit tedious: you don't need add the normal fields to the models, so why we need to add the relations??. But anyway I think is better to try write things in one and only one place. So I think it was wonderful if meta-rails can add the belongs_to from the migrations files directly. Maybe we need some help in order to do that: something like an "anotation" or "hint" in the migrations file. This way, you don't have 2 files to drive your models...

2008/1/22, Sergio Espeja <sergio...@gmail.com>:

[Piotr Kopszak]

That's probably the right idea if you want to develop further a
MetaRails app, and
obviously everybody wants that, and not lose the possibility of using
MetaRails in the process.
Or maybe load MetaRails definitions into model files from separate
files. Would it make things
unnecessarily complicated?

Piotr

On 22 Sty, 09:54, "Sergio Espeja" <sergio.esp...@gmail.com> wrote:
> Hello Piotr!
>
> Currently metarails can make modifications to the database using migrations
> but don't modify the rails models. Make changes to the database with
> migrations are so easy because you only have to add the changes in new
> migration files, but change the models is a little bit more difficult
> because you can overwrite custom code...
>
> MetaRails plans to implement this functionality, the first aproach will be
> to change the code between:
> # Code generated by MetaScaffold BEGIN
> ...
> # Code generated by MetaScaffold END
>
> Any other ideas?
> Sergio
>

[Sergio Espeja]

I think that one good solution could be to make rails read the database definition YAML during the initialization process, then rails could take the model relationships from this file. This will lead to leave the rails models clean of relation definitions.

But I think that rails migrations must behave as they do, because one of the best features of migrations is that you can go up and down trough them knowing exactly what you have in the database. And you can make changes to the db creating a new migration and this changes will be reproduced exactly to other users of the application just updating its code and calling "rake db:migrate".

In summary, my proposal is to have a meta rails database definition YAML, with this file we can create the migrations automatically and infer the rails models relations. The rails models files can exist or not depending if we want to add extra methods to them. This won't be difficult to develop (see http://magicmodels.rubyforge.org/).

Jorge, do you agree?
Piotr, is this yaml file the one that you are thinking on?

Sergio

[Piotr Kopszak]

Yes, of course, that's the file I was thinking of! This solution
sounds great, although I must say the code MetaRails puts into model
files helped me understand more or less how it works, so maybe you
could leave it as an option to have the Meta Rails code included the
model files the way it is now, if anybody wants it.

Piotr

[Jorge L. Cangas]

I'm sorry but disagree: At this point I think MetaRails (MR) is going
in the opposite direction. Migrations files are more importatn and we
cannot generate wihtout break or confuse the user: in migrations files
we can add more than tables and fields, we can write indexes and maybe
other SQL stuff.
Today MR, read the Database to infer models. So we have to fight with
DB, yml models & migratrions files. Too many points to one concept:
this is a bad smell IMHO.
Solution?
I think we need reverse the problem: extend the migrations file. Our
user put all the relevant info in one point: the migrations files, and
MR forget aboout DB & yaml. How can do it?. See that:


# inspired by SexyMigrations
module MetaMigrations
module Table
def belogns_to(*args)
options = args.last.is_a?(Hash) ? args.pop : {}
args.each do |col|
column(id = "#{col}_id", :integer, options)
if options[:ref]
reference = options[:ref] == true ? col.to_s.tableize :
options[:ref].to_s
(@fk_references ||= []) << [id, reference]
end
end
end

def inheritable
string :type
end
end

module Schema
alias real_create_table create_table
def create_table(name, options = {}, &block)
create_yml_model(name, options, block)
real_create_table(name, options, block)
end

alias real_drop_table drop_table
def drop_table(name)
drop_yml_model(name, options, block)
real_drop_table(name, options, block)
end
end
end
ActiveRecord::ConnectionAdapters::TableDefinition.send :include,
MetaMigrations::Table
ActiveRecord::ConnectionAdapters::AbstractAdapter.send :include,
MetaMigrations::Schema

Here I try to show how we can hook migrations files and create the
same current yml models, but without the yml files. Of course this is
only a guess, but I'm pretty confident I can write the real code. This
way we get some callbacks to infer our class model using only the
migrations files, no yml, no db.
I hope you understand the idea: my English is limited :)

What do you think about this crazy idea? Seeing any problem?

On Feb 1, 2:16 pm, "Sergio Espeja" <sergio.esp...@gmail.com> wrote:
> I think that one good solution could be to make rails read the database
> definition YAML during the initialization process, then rails could take the
> model relationships from this file. This will lead to leave the rails models
> clean of relation definitions.
>
> But I think that rails migrations must behave as they do, because one of the
> best features of migrations is that you can go up and down trough them
> knowing exactly what you have in the database. And you can make changes to
> the db creating a new migration and this changes will be reproduced exactly
> to other users of the application just updating its code and calling "rake
> db:migrate".
>
> In summary, my proposal is to have a meta rails database definition YAML,
> with this file we can create the migrations automatically and infer the
> rails models relations. The rails models files can exist or not depending if
> we want to add extra methods to them. This won't be difficult to develop

> (seehttp://magicmodels.rubyforge.org/).

>
> Jorge, do you agree?
> Piotr, is this yaml file the one that you are thinking on?
>
> Sergio

[Thufir]

I've never heard of meta rails before, but I like the sound of it :)

If the problem is that information is spread through yaml files,
migration files and models, then the question is: where can this
redundancy be eliminated?

I concur, eliminate it from the yaml and model, because it *cannot* be
eliminated from the migration.

The migration has essential data, field names for the db.


-Thufir

[Piotr Kopszak]

Yes, but one of the good things about MetaRails, in my opinion, is the
very possibility of genereting migrations from the yaml file which is
more concise, easier to read, whatever you want. And don't forget that
it is possible to use (a limited, but anyway) xml instead of yaml,
which gives enormous possibilities.
I would rather get rid of migrations, if it was a question of taste
only. Unfortunately it isn't.

Piotr