Generator to install rodauth using alternative accounts_table

[bekicot]

running

rails g rodauth:install users

should generate rodauth migrations, model, and configurations that works with users table.

Issues from @janko:

This might be possible for the initial rodauth:install run, but how would this work for any subsequent rodauth:migration runs? It would have to inject *_table declarations into the Rodauth configuration, but how would it know where it should do that? If I would introduce this feature, it would have to be all the way.

Related to: #194, #180, #56, #31, #23

Related wiki: https://github.com/janko/rodauth-rails/wiki/Account-Types

[danielb2]

For example, if the accounts_table is set to :users, it will automatically assume the model class of User.

This is unclear. How to set accounts_table now? Wouldn't this just be a matter or original configuration?

Update:

Looking here helped #180

I think the doc could be updated. It seems having a table_prefix would make things easier. For example, I just want to replace account with user everywhere.

    accounts_table :users
    verify_account_table :user_verification_keys
    verify_login_change_table :user_login_change_keys
    reset_password_table :user_password_reset_keys
    remember_table :user_remember_keys

would be:

    table_prefix :user

for example

[janko]

@danielb2 I've been exploring your table_prefix idea (I like this naming the most 🙂), and there is a way to redefine all *_table and *_account_id_column methods at the time when they're all defined, by doing it in the #post_configure method intended for internal use.

In addition to this, I would also like to implement rails g rodauth:install users proposed by @bekicot. The complete this, I think we should also update the rodauth:migration generator to automatically generates the correct table names, either by adding --name to reference the Rodauth configuration, or --prefix that's unrelated to Rodauth config (proposed by @nicolas-besnard in #31).

I plan to make a next release with all these additions, which I believe will improve the overall story around using alternative table names.

[danielb2]

That's great!

When you say adding --name what would the command look like? Something I typically do is right out the different options I have in mind, and compare them side by side, and wonder which one, as someone using the code, would be the most intuitive to use.

[janko]

When I was writing the answer, I realized that the --name approach wouldn't work all the way, even if we put aside that --name is already taken, which I completely forgot about 🙈

Let's say we have the following:

class RodauthAdmin < RodauthBase
  configure do
    table_prefix :admin
  end
end

class RodauthApp < Rodauth::Rails::App
  configure RodauthAdmin, :admin
end

And want to enable the active_sessions feature. The idea behind the --name approach was that the generator would find the Rodauth configuration registered under that name in RodauthApp, and read the actual table name set up there. However, this would require the generator to enable the feature if it hasn't already been enabled (in order to get the *_table method), which will fail for features whose dependencies aren't yet installed. And I really want to avoid requiring developers to do things in a certain order.

The --prefix approach would just generate tables with the given prefix, unrelated to what you have in your Rodauth configuration. Now that I thought about it more, it's a much simpler approach, and the naming nicely links to the table_prefix we'd have. If you just have a default configuration with a user prefix, you'd still need to append --prefix user to every rodauth:migration command, which might not be necessary with the --name approach (because missing --name could imply default configuration), but I think it's an OK tradeoff for internal simplicity and reliable behavior.

What do you think?

[janko]

Just pushed the table_prefix configuration method to main, feel free to try it out 😉

[danielb2]

will do. that's awesome!

What do you think?

I haven't had a chance to think about this. I think I still need to see this in context since this is my first dealings with rodauth. I chose it because it's by Jeremy Evans and I love his development philosophies and work on sequel

[janko]

In addition to the table_prefix configuration method, I've just added a --prefix option to the migration generator, as well as a table argument to the install generator, which sets table_prefix in the Rodauth migration and uses --prefix when generating migrations.

I believe this now completes the story around making it easier to use table names different than "account", both for single and multiple Rodauth configurations. I would appreciate any feedback if this is now easy enough to work with 🙂

[janko]

I ended up removing the new table_prefix configuration method, as I decided it's not worth diverging from what vanilla Rodauth offers. This functionality would be unrelated to Rails, and I would like to avoid creating a "Rails flavor" of Rodauth.

I will modify the rodauth:migration generator to print Rodauth configuration when --prefix was specified, which the developer can copy-paste. The rodauth:install generator will now generate the appropriate *_table overrides for the default features when the table argument is passed in, otherwise we'll show commented out examples. These changes should hopefully prevent the developer from having to look up correct *_table and *_account_id_column configuration methods.

[danielb2]

I would like to avoid creating a "Rails flavor" of Rodauth.

and for rodauth, you would need to modify each of the individual table names as well? IOW, table_prefix suggestion should/could be made in the rodauth project ?

[janko]

That's correct 👍🏻