Remove unused documents in the modules database

[prestonmcgowan]

When the code is deployed using deploy modules my code is deployed to the server.

When I remove a document from the codebase, the document still exists on the modules database.

Can there be a option to wipe all documents prior to loading the modules to ensure no old code is still lying around?

[paxtonhare]

Good one. This has bitten me several times. The problem is that, unless we just wipe first on deploy, it will always fall on the user to remember to do it.

right now you can do this:

./ml local clean modules local deploy modules

and that will make it happen.

Also, you can hack your app_specific.rb to do this:

  alias_method :original_deploy_modules, :deploy_modules
  def deploy_modules
    clean_modules
    original_deploy_modules
  end

You are monkey patching the deploy_modules to call your custom method instead. It's great for adding custom steps to the deploy process.

I'm not sure how I feel about always cleaning before deploying and making that the default for the world.

Anyone else have opinions?

[prestonmcgowan]

I didn't know that you could chain deployment tasks.

I was thinking of just

./ml local deploy modules --clean

[prestonmcgowan]

Secondary thought, might warrant another "issue". What about a command to effectively "ls" the modules database and say what is missing or not in the filesystem codebase?

This would let you find deployed files that are messing you up. ... Not that I have ever had this happen ;-)

[dmcassel]

I like "ml local deploy modules --clean", actually. I know my way around Roxy pretty well and I still forget about chaining commands.

I'm trying to think of situations where cleaning by default would be bad. Other than the extra run time, it would only be a problem if your app is writing some state to the modules database. Not impossible, but seems uncommon to say the least.

[prestonmcgowan]

If you and I are both working on an application but our services are in different code bases, when you deploy your code it would hopefully not remove mine.

That is the first example I could think of where "auto-clean" would be bad.

[dmcassel]

Good point. Okay, I like having "--clean" option, even though it would be functionally the same as chain.

[grtjn]

A --clean flag should be very easy to implement..

[grtjn]

Though, instead of doing a forest-clear, it could try to discover uris on the server, determine delta, and delete the redundant ones. Bit like how --incremental works, but then the other way around. Could save unnecessary time, particularly when combined with --incremental..