Restriction in dm-rails create/drop rake tasks

[John E. Vincent]

I was curious what the reason for the localhost restriction on
dm:create and dm:drop in dm-rails. Padrino is actually using a port of
the dm-rails rake tasks and, in the process of troubleshooting a
different issue, I noticed this. I've made a pull request for the fix
in the padrino dm rake tasks and would be willing to port it over to
dm-rails.

What was the validation/reasoning behind the restriction?

As a side note, why is the mysql command-line used/required to do
this? If the user defined has permissions to create/drop databases,
this could be done via SQL and make the process even easier instead of
calling system().

You can see the changes I made to the padrino rake task here:

http://github.com/lusis/padrino-framework/commit/b86930fcdd556fa57797c60ca2aa8c332fa1663c

[Martin Gamsjaeger]

John,

1) The restriction is there because that's how AR handles it too
2) I'm not exactly sure how you mean "this could be done by SQL"?

cheers
snusnu

> --
> You received this message because you are subscribed to the Google Groups "DataMapper" group.
> To post to this group, send email to datam...@googlegroups.com.
> To unsubscribe from this group, send email to datamapper+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
>
>

[John E. Vincent]

snusnu,

1) Is there any objection to changing it? I'll poke around and see why
AR has the same restriction.
2) I probably wasn't clear. You could use a regular SQL call over tcp/
3306 or unix socket to create the database as opposed to using the
system() call. Use the ruby mysql api directly.

My point was that, if you have permissions to create the database, you
have permissions to connect via socket as well and create the
database. It's honestly a minor issue but tangentially related to
remote connections in create/drop. create/drop on a remote host was a
bigger one for me as I have a dedicated database vm I use for
development.

On Jul 2, 2:39 pm, Martin Gamsjaeger <gamsnj...@gmail.com> wrote:
> John,
>
> 1) The restriction is there because that's how AR handles it too
> 2) I'm not exactly sure how you mean "this could be done by SQL"?
>
> cheers
> snusnu
>

> On Fri, Jul 2, 2010 at 20:05, John E. Vincent <lusis....@gmail.com> wrote:
>
>
>
> > I was curious what the reason for the localhost restriction on
> > dm:create and dm:drop in dm-rails. Padrino is actually using a port of
> > the dm-rails rake tasks and, in the process of troubleshooting a
> > different issue, I noticed this. I've made a pull request for the fix
> > in the padrino dm rake tasks and would be willing to port it over to
> > dm-rails.
>
> > What was the validation/reasoning behind the restriction?
>
> > As a side note, why is the mysql command-line used/required to do
> > this? If the user defined has permissions to create/drop databases,
> > this could be done via SQL and make the process even easier instead of
> > calling system().
>
> > You can see the changes I made to the padrino rake task here:
>

> >http://github.com/lusis/padrino-framework/commit/b86930fcdd556fa57797...

[John E. Vincent]

I just did some digging and AR no longer has the remote host
restriction. Additionally, they no longer call system() to create the
database. I can fork and request pull for fixing the remote host issue
but it will take some time to change the system() logic. Assuming no
one has any objections?