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
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
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
> 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
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
osas :
> 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 t
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
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 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
Il giorno 10/mag/2012, alle ore 09.28, Nick Sutterer ha scritto:
>
>
> On Wednesday, May 9, 2012 12:36:26 AM UTC+2, Ryan Bigg wrote:
> I've been developing engines (Forem: https://github.com/radar/forem and
> Spree: https://github.com/spree/spree) for a while, and I've always chosen to
> make
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
Il giorno 03/giu/2012, alle ore 13.35, Andrew White ha scritto:
>
> At some point (I don't know when) it was decided that rather than
> constructing SQL out of string fragments, Rails 3 would use Arel to build SQL
> but with a separate query interface that maintained backwards compatibility
> b
Il giorno 03/giu/2012, alle ore 15.17, Ken Collins ha scritto:
>
> On Jun 3, 2012, at 7:35 AM, Andrew White wrote:
>
>> At some point (I don't know when) it was decided that rather than
>> constructing SQL out of string fragments, Rails 3 would use Arel to build
>> SQL but with a separate que
Il giorno 04/giu/2012, alle ore 23.27, Bruce Perens ha scritto:
> Sequel looks interesting. At first glance, it looks more mature than AR, and
> I guess shows how AR might evolve. Of course, I know nothing about its
> performance, etc. I might try it in my next application.
Yes, AR might evol
Rodrigo Rosenfeld Rosas:
> Lack of documentation, support, and a good-enough API. All of that I've found
> in Sequel and it further performed better than AR, so yay! ;)
>
> Pretty happy with the move and I sincerely wish the best of luck for AR to
> get over the "80%" it currently supports...
A
Il giorno 05/giu/2012, alle ore 03.56, Rodrigo Rosenfeld Rosas ha scritto:
> Em 04-06-2012 20:47, Maurizio Casimirri escreveu:
>>
>> Rodrigo Rosenfeld Rosas:
>>> Lack of documentation, support, and a good-enough API. All of that I've
>>> found in Sequel a
>
> Sorry, but I have no idea what you're talking about. Could you please give me
> an example of one of those AR plugins you're referring to?
>
Sorry, you are right i was referring to gems that involve querying the database
through AR, Devise to say one that yourself mentioned.
As in a past
Il giorno 05/giu/2012, alle ore 13.55, Rodrigo Rosenfeld Rosas ha scritto:
> Em 05-06-2012 00:17, Maurizio Casimirri escreveu:
>>
>>>
>>> Sorry, but I have no idea what you're talking about. Could you please give
>>> me an example of on
No problem ;)
Il giorno 02/ago/2012, alle ore 01.33, Steve Klabnik ha scritto:
> Sigh, I'm an idiot and mis-read your email. Please ignore my last one. :[
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group,
@ Aaron Patterson
> I'm not really a fan of this. When I read this code, it's difficult to
> understand how ":create" is related to "Post".
Yes, I've not focused too much on the syntax, probably there are a lot of
better ways to express the same thing, also it would been better if i've used
20 matches
Mail list logo
