ActiveRecord: private versus protected methods

Hi,

I'm considering subclassing ActiveRecord::Migrator to
enhance the way
it tracks the migration version number of a database. 
However there's
a hurdle: it has private methods.

Private methods are a major stumbling block for anyone
needing to
sub-class something.  If the public methods of the class
call the
private methods, you can't sub-class without replacing all
the private
methods (because otherwise they won't be available in the
descendant
class).

A much better approach is to declare methods as 'protected'.
 That
offers a lot more flexibility:

* The methods are still protected from being called from
outside the
class.

* The class can be sub-classed, and it will still work.

Does anyone know: is there a compelling reason for using
'private' in
this case?  Are there any core developers listening?  Can
you make your
methods 'protected' instead of 'private' please?

I really don't want to have to maintain my own fork of
ActiveRecord::Migrator.


Thanks and regards,
Urbanus
http://goldberg.240gl.org


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http:
//groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

Hi Jeremy,

> You need protected only if you wish the call the method
from a subclass. The

Exactly.  That's the issue.

> inherited public method is not affected. Please bring
up specific examples
> (preferably as Trac tickets) and we will address them.

I'm considering a fairly deep change to the way migrations
work.  I'm
looking at adding a *namespace* to migrations, so when doing
a
migration you would specify the name and version number for
the
required migration.

This would allow you to deploy parts of Rails apps as a kind
of
plug-in.  So when you migrate up or down, you can specify
which part of
the database you're referring to.

For example, you might have a Rails app called
"portal" that provides
all the core functionality of your website, into which you
can add
optional plug-ins such as "cms",
"discussion_board", etc.  Each of
those plug-ins would have their own database requirements,
in addition
to the main "portal".

I'm also looking at dependencies between the parts, e.g.
"cms" version
4 might depend on "portal" version 2 or above.

Rails migrations almost do what I need; except that you
can't put
different sorts of migrations into the one Rails database
(AFAIK).

I could do all this using the existing migration classes as
a basis if
-- as discussed previously -- I could sub-class them and
override their
public methods.  But I can't, because the public methods
rely on
private methods.

Thanks,
Urbanus


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http:
//groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

> Exactly.  That's the issue.

It's not strictly true.  Private Methods can't be called
with a
receiver,  that's all.   So

class Base
  private
  def foo
    1
  end
end

class Derived < Base
  def calls_foo
    foo
  end
end

Derived.new.calls_foo will work perfectly.


> > inherited public method is not affected. Please
bring up specific examples
> > (preferably as Trac tickets) and we will address
them.
>
> I'm considering a fairly deep change to the way
migrations work.  I'm
> looking at adding a *namespace* to migrations, so when
doing a
> migration you would specify the name and version number
for the
> required migration.

This sounds a little like what the engines guys have done
with
migrations,  perhaps you can investigate how they
implemented it?

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http:
//groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

Thanks Koz, that was very helpful.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http:
//groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

On Wed, Sep 27, 2006 at 07:48:29PM -0700, urbanus wrote:
> Rails migrations almost do what I need; except that you
can't put
> different sorts of migrations into the one Rails
database (AFAIK).

A couple of guys at a client of mine implemented this, and
it involved
opening up one method to the outside world to specify the
name of the
schema_info table (we used schema_info_<name> for the
different parts).  It
was quite small and simple.  They didn't subclass, but as
Koz mentioned
private methods don't necessarily preclude subclassing.

The other stuff you're talking about (schema chunk
dependencies) would be
trickier, but I'd be inclined to leave that to
application-level
dependencies (surely you're going to need code to go along
with those
schemas, so tying it all up into a single version number
thing would be
pretty clean).

- Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http:
//groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

wait, you CAN put diffferent sorts of migrations into ont
Rails Database.
through engine plugins. take the login_engine plugin as an
example.
it includes its own migration which are separate set from
the
applications migrations.
each engine plugins can have their own. you might not need
to extend
migrator at all.

sqlite> .schema engine_schema_info
CREATE TABLE engine_schema_info (engine_name varchar(255),
version integer);
sqlite> .schema schema_info
CREATE TABLE schema_info (version integer);
sqlite> select * from schema_info;
14
sqlite> select * from engine_schema_info;
login_engine|1
sqlite>

regards,

On 9/28/06, urbanus <urbanus240gl.org> wrote:
>
> Hi Jeremy,
>
> > You need protected only if you wish the call the
method from a subclass. The
>
> Exactly.  That's the issue.
>
> > inherited public method is not affected. Please
bring up specific examples
> > (preferably as Trac tickets) and we will address
them.
>
> I'm considering a fairly deep change to the way
migrations work.  I'm
> looking at adding a *namespace* to migrations, so when
doing a
> migration you would specify the name and version number
for the
> required migration.
>
> This would allow you to deploy parts of Rails apps as a
kind of
> plug-in.  So when you migrate up or down, you can
specify which part of
> the database you're referring to.
>
> For example, you might have a Rails app called
"portal" that provides
> all the core functionality of your website, into which
you can add
> optional plug-ins such as "cms",
"discussion_board", etc.  Each of
> those plug-ins would have their own database
requirements, in addition
> to the main "portal".
>
> I'm also looking at dependencies between the parts,
e.g. "cms" version
> 4 might depend on "portal" version 2 or
above.
>
> Rails migrations almost do what I need; except that you
can't put
> different sorts of migrations into the one Rails
database (AFAIK).
>
> I could do all this using the existing migration
classes as a basis if
> -- as discussed previously -- I could sub-class them
and override their
> public methods.  But I can't, because the public
methods rely on
> private methods.
>
> Thanks,
> Urbanus
>
>
> >
>


-- 
gcc -O0  -DRUBY_EXPORT   -rdynamic -Wl,-export-dynamic -L.  
main.o
-lruby-static -ldl -lcrypt -lm   -o ruby
Everyone is trying their hardest to do their job but
management has
set it up so that it's impossible.
Take the control over your money, track your expenses http://justbudget.com

Mathieu

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http:
//groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

Yes.  Michael pointed this out.  The Engines guys seem to
have the
right approach IMHO.  The idea (or at least MY idea) would
be to have a
similar mechanism but distinct from the whole Engines
framework.


Regards,
Dave


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http:
//groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---

my question is WHY ? would not your plugins includes more
than just
migrations? Would not you be able to acheive everything you
want with
rails engines? if something is lacking in the rails engine,
would not
you want to extend this engine system instead?

On 10/3/06, urbanus <urbanus240gl.org> wrote:
>
> Yes.  Michael pointed this out.  The Engines guys seem
to have the
> right approach IMHO.  The idea (or at least MY idea)
would be to have a
> similar mechanism but distinct from the whole Engines
framework.
>
>
> Regards,
> Dave
>
>
> >
>


-- 
gcc -O0  -DRUBY_EXPORT   -rdynamic -Wl,-export-dynamic -L.  
main.o
-lruby-static -ldl -lcrypt -lm   -o ruby
Everyone is trying their hardest to do their job but
management has
set it up so that it's impossible.
Take the control over your money, track your expenses http://justbudget.com

Mathieu

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http:
//groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---