meteor-rethinkdb
meteor-rethinkdb copied to clipboard
Auto create tables
Would be nice to automatically create tables that are declared but not present in db?

It will trip people up, even if explained in readme
The rethinkdb driver doesn't autocreate tables. Why would Meteor do this?
- To match the behavior of making Meteor Mongo.Collections
- Making things easier for developer
Yeah, I don't know if this is what RethinkDB developers would expect. We can certainly do this, but it is kinda weird given that Rethink has an explicit command for creating tables.
They might not expect it, but if they're declaring the table and it doesn't exist, they want it to exist, and so we're doing them a favor. IMO a net good
On Fri, May 1, 2015 at 5:33 PM, Slava Kim [email protected] wrote:
Yeah, I don't know if this is what RethinkDB developers would expect. We can certainly do this, but it is kinda weird given that Rethink has an explicit command for creating tables.
— Reply to this email directly or view it on GitHub https://github.com/Slava/meteor-rethinkdb/issues/4#issuecomment-98269706 .
Or you misspelled the name of the table and now you have two tables. In mongo at least the collection is not created if nothing was written to it.
Please add these to neumino/reglite#3.
I might hope that developers will detect "misspelled table names" while they're still actively writing their code. It is unlikely that unwanted tables will be created in a production environment.
If the final word about this is indeed to not auto-create tables, I would suggest adding an option or method to make the code create the table, and not require a db-admin to dive into the database administration interface.
Something like
new Rethink.Table('players', { autocreate: true });
Or, inspired by the mongo _ensureIndex method:
Players = new Rethink.Table('players');
Players.ensureTableExists(true);
Agree with above post. It's no fun when you have a ton of tables and every time you deploy your app you have to create them all manually.
I think an autocreate flag might not be a bad idea. I just don't want to introduce any default behavior that is not expected from a raw RethinkDB driver. Especially, if it is modeled after MongoDB.
I don't know if this should be in a separate issue, but should we also account for custom primary key field names? In RethinkDB when you create a table, there's an option to set the name of the auto-generated primary key, which if not set, defaults to id. This is different from MongoDB, which makes _id the only primary key.