2012/5/10 Matt Jones :
> I believe most developers would regard the second form as more
> understandable, especially if they were new to the codebase.
>
Yes they will ;)
> In the case of hobofields, there was the additional need to have
> more-specific type information for use by code that ess
I'm one of the maintainers of the hobofields gem Andrew Mutz mentioned earlier,
so I figured I'd toss my observations in.
To me, an in-model DSL provides two major benefits:
- enhanced readability of the class, both for the developer and for other code.
For instance, compare these two models (l
2012/5/9 James B. Byrne :
>
> On Wed, May 9, 2012 14:55, Maurizio Casimirri wrote:
>
>>
>> The only case in which the generator fails to generate is when the
>> state of the database is not updated respect to migrations, but no
>> problem arises if we use two different models refering to same table
On Wed, May 9, 2012 14:55, Maurizio Casimirri wrote:
>
> The only case in which the generator fails to generate is when the
> state of the database is not updated respect to migrations, but no
> problem arises if we use two different models refering to same table,
> only the differences will be t
2012/5/9 Rodrigo Rosenfeld Rosas :
> Em 09-05-2012 15:46, James Coleman escreveu:
>
>> I would love to see the properties available on that specific Ruby model
>> defined by annotations--much like relationship methods define what
>> relationships are available on any given model. But I do not belie
2012/5/9 James B. Byrne :
>
> On Wed, May 9, 2012 13:35, Maurizio Casimirri wrote:
>
>>
>> Migrations are meaningless outside active record (again the pattern
>> not the gem).. we can't enforce a migration centered approach in an
>> ORM agnostic environment.. perhaps to me it seems that is more
>>
Em 09-05-2012 15:46, James Coleman escreveu:
I would love to see the properties available on that specific Ruby
model defined by annotations--much like relationship methods define
what relationships are available on any given model. But I do not
believe that this should flow backward into gener
I would love to see the properties available on that specific Ruby model
defined by annotations--much like relationship methods define what
relationships are available on any given model. But I do not believe that
this should flow backward into generation migrations.
If the model and the migration
On Wed, May 9, 2012 13:35, Maurizio Casimirri wrote:
>
> Migrations are meaningless outside active record (again the pattern
> not the gem).. we can't enforce a migration centered approach in an
> ORM agnostic environment.. perhaps to me it seems that is more
> comfortable to make ActiveRecord to
I understand your opinion but i'm not introducing, and not inventing
nothing new. Plus Sequel is active record (the pattern not the
library).. just try with mongoid or mongomapper..
Rails will get more orm agnostic because you will have the ability to
switch between orms that already support that
Em 09-05-2012 12:06, Maurizio Casimirri escreveu:
Yes, i'm sorry .. examples.. anyway: declaring fields in models should not be
mandatory! To keep track of renaming, changing and deleting of columns is
already up to the migration system. We could think to a rake task to check if
everything is
Yes, i'm sorry .. examples.. anyway: declaring fields in models should not be
mandatory! To keep track of renaming, changing and deleting of columns is
already up to the migration system. We could think to a rake task to check if
everything is up-to-date.. (few line of code) but i don't care too
Em 09-05-2012 10:52, Maurizio Casimirri escreveu:
Back to the subject:
I've tried to convince you not to argue about defining the properties
inside the models to avoid duplication of code in migrations because
they should be really isolated from each other from my point of view
... From your
> 2 - application-specific classes can't be used inside migrations (is this
> really a disadvantage?)
agree.
> Some people like the idea of updating some data in the database during a
> migration by using the ORM itself inside the migrations.
>
> While this can be handy sometimes, it can crea
> The solution provided by Rails is to use "rake db:setup" for fresh
> databases, but what if you need to run several migrations because you
> already have a database, but the code has changed in such a way that some of
> the earlier migration code won't run anymore?
This is off-topic.
You need to
I wouldn't go for this route when trying to convince one.
IMO database migration and the ORM are different concerns and we should
actually use the single responsibility principle with regards to them.
For example, I prefer to maintain my database migrations in a different
project using standa
Between Content and Article and Content and Video? Something like
Content belongs_to content_owner? Probably this is also a solution,
anyway this is not the point.
Now, i agree this example is really poor, try to figure out a
situation were STI fits better if you like but, rather to debate if
STI
On 9 May 2012 11:29, mcasimir wrote:
> About 'this is duplicated code': what about STI?
>
> eg
> class Content < AR::Base
> class Article < Content
> class Video < Content
>
> Here Video instances will respond to :text, and Article will respond_to :url
> without batting an eye. moreover even in th
No other answer? I do not have you convinced yet then .. I hope that does
not bother you if I try again.
About 'this is not active record': with ruby ActiveRecord you have improved
the pattern yet mixing it with STI and supporting associations with macros.
About 'this is duplicated code': what a
I've checked that gem before to implement my third-party solution..
https://github.com/mcasimir/active_record_schema, it's very similar to
hobo_fields.
I'm not intrested in promote it but to encourage you to at least be
doubtful that such a solution is to consider more calmly.
Think of the benefi
There are incredible benefits to separate migrations from the model.
Also note that it is not so obvious that the procedural code to write
and track changes to the database code is 'duplicate' of what defines
the abstract structure of application domain.
Advantages, some philosophical, some more p
Clearly this isn't the ActiveRecord approach, where what is in the table is
the authoritative view. If you want to use ActiveRecord in a style where
the models contain the authoritative view, check out the third-party
library HoboFields:
http://cookbook.hobocentral.net/manual/hobo_fields
It give
Seems like unnecessary duplication if you have to specify the field in a
migration as well as in the model itself.
What's the point of having to specify the field on the model if it's
already in the table? Unless there is some other benefit that I am not
seeing right away.
--
You received thi
23 matches
Mail list logo
