No Remove method in the API?

[toymachiner62]

I noticed there is an insert command in the API, but no remove method.

Was this done on purpose or is the remove method just missing?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/8424611-no-remove-method-in-the-api?utm_campaign=plugin&utm_content=tracker%2F73887&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F73887&utm_medium=issues&utm_source=github).

[wzrdtales]

It's just missing, if we're pendantic one could say inserting data is part of a seeder but not of a migration.

And I'm not sure yet, If I wouldn't want to separate this.

Going to think about this a bit longer, before giving a more elaborated answer.
Thoughts from the community are welcome as always ;)

[toymachiner62]

True, but this lib contains everything needed to also be a seeder as well as a migration library since you can run raw sql.

[toymachiner62]

If it just had a couple more methods such as remove it could easily also be used to seed without having to use raw sql.

[wzrdtales]

There is a difference between, enabled by design and abused by design :)

[wzrdtales]

Generally it may not hurt to implement full seeding capabilities, but I don't like the Idea of a migration that leads to bad design decisions.

Also seeding and migrations I think is something anyone should carefully separate. Especially when working with foreign keys and constraints, things quickly collide.

[wzrdtales]

May be it's a step in the right direction to have seeding capabilities within db-migrate, but to enforce them not being in the same scope. Thus there are single routines and also folders for both, but I'm not sure yet.

[wzrdtales]

Nevertheless, a remove method and general seeding capabilities should be a part of db-migrate, so they could be implemented.

But in long term there should be a separation from migrations to seeders.

Thoughts?

[toymachiner62]

Yea i think they should be separate as well. I always think of the way that Ruby on Rails works with migrations and seeds. They have a separate folder for seeds and a separate folder for migrations. There is also separate commands for each rake db:migrate vs rake db:seed.

[toymachiner62]

I guess though in my case maybe what i'm wanting is to be able to write seed commands in a migration because even in Rails you can reseed multiple times and get duplicate data.

I'll explain my use case in a bit.

[toymachiner62]

My use case is that I want to populate a mongodb collection with new data periodically without having to worry about creating duplicate data.

I have an authorizedUsers collection for example which is a list of users that are authorized to use my app. If I need to give access to a new user, I want to be able to add that user in an insert statement in a migration and run the migration.

This allows me to run the migration on multiple environments to easily add that user to all the environments. The reason that I like this better than seeding is that seeding can be run multiple times and can cause duplicate data b/c seeds are not kept track like migrations are.

[wzrdtales]

So this may be a case for a version controlled seeder, instead of invoking them from the migrations?

[toymachiner62]

Yea i guess so. That'd be a great feature.

[wzrdtales]

Okay, gets right on my ToDo List

[wzrdtales]

related to #215

[kimmobrunfeldt]

I'm already using Mongoose in my project, do you see it as an issue to use Mongoose API inside up and down functions? Anyways I would prefer to use a more complete API for modifications in mongo

[kimmobrunfeldt]

I would need to be able to for example add a new attribute for all documents inside my collection. Real world example: I have users collection and I would want to add a new 'column' called age for all the existing users too.

[wzrdtales]

@kimmobrunfeldt Ic, this makes sense, from the perspective of a migrator now, the question is. If we edit a schema, also if this is a NoSQL one, shouldn't we already be able to do this via the addColumn,.. methods and be able to flag it to apply it just to one document or to all.

I think I'm going to create a concept on this topic and open a RFC for this. But first I'm going to push through the v0.10.x the next weeks which already introduce a whole bunch of new features, which prepare the way into the future.

To answer your other question, it is not a problem if you use mongoose, but that is just your decision to handle a problem, I wont consider this as an issue, but I consider the missing ability to fully manage a system via the driver as one.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.