db.remove is missed

[hyzhak]

it seems that there is missed implementation of remove method https://github.com/db-migrate/english-docs/blob/master/API/Seeder.md#removetable-ids-callback

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29159999-db-remove-is-missed?utm_campaign=plugin&utm_content=tracker%2F12293389&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F12293389&utm_medium=issues&utm_source=github).

[wzrdtales]

Yes that is true, there is currently already some existing documentation of features that are going to be introduced soon. You may also should have noticed that seeders are not yet that far available to you. This in progress, though.

Depending on the version you use, expect that the actual documentation already displays the behavior how it should be for the beta version, but may not be already existent. This is especially true for seeders as they're beeing introduced with v0.10.x first.

[wzrdtales]

the master and v0.10.x branch of the documentation is even, though. if you are currently using the v0.9.x version then you might also depend on the v0.9.x version of the docs.

[hyzhak]

oh, I see, it is a little bit confusing, because mongo adapter doesn't have any v0.9.x versions at all https://github.com/db-migrate/mongodb/releases so it will be much better to have synced versions of docs and libs. And btw mongo adapter supports db.insert function so it is strange to have insert without remove, because we always should have something for up and something for down. Anyway do you have certain plans about mongodb adapter? Are you open to PR?

[wzrdtales]

ok, let me explain that a bit :)

before v0.10.x (which is currently in beta) there weren't any adapters. mongodb was at that point still part of the main project.

To say I'm absolutely open for PRs, if you would like to help, this would be amazing, And yes I have plans for the mongodb adapater, to say the thing about seeders and migrations apply to all kind of drivers/adapters. There should be a clear separation of just doing data definition (migrations) and data manipulation/transformation (seeders), while those two can be linked to each other. A migration can call a seeder and a seeder might call a migration.

Generally also to note there are two kind of seeders:

• static Seeders

These are the traditional ones, you execute them and thats all, they are not capable of rolling back. They are pretty that what you may know from the laravel seeders, which are pretty awful for specific tasks, but that is the reason why there are the other seeders.

• version controlled seeders or short vc seeders

These are seeders that behave like migrations, they can be rolled back, have an up and down function and can get part of the whole migration suite.

What I am generally aiming for is a database migration suite that is capable of providing all needed capabilities for modern needs:

• zero downtime deployments
• automatic provisioning
• completely automated deployments
• completely automated rollbacks

If you want to help out here, I'm open for talks, ideas, PRs and everything else you can think of! Please feel free to ask questions, make suggestions, text me on jabber/xmpp (tobi@wizardtales.com), or mail me or anything that suites you best :)