[ditz-talk] Does ditz need some kind of relational DB or searching / indexing engine?

Nolan Darilek nolan at thewordnerd.info
Thu Oct 30 18:56:55 EDT 2008

I think that SQLite would be out of the question since it's a binary 
format, and Ditz needs to rely on textual mergingg for conflict-resolution.

I wonder, though, if something like http://stone.rubyforge.org would be 
a good fit? It provides a DM-like view onto a simple YAML datastore, 
supporting searching and such. For that matter, I think DM has a 
YAML-based storage layer that would likely accomplish the same thing.

This actually dovetails with a thought I've been having recently: 
RESTful Ditz. Instead of a bunch of commands, make the structure more 
REST-like. So you'd have "ditz issue add", "ditz release drop," etc. 
Then alias a few shortcuts, so "ditz add" and drop would reference 
issues, thus making the common case more quick. This would likely make 
it easy to spot gaps in command coverage, like the missing command to 
drop a release for instance. :)

On 10/30/2008 10:28 AM, Matthew Wilson wrote:
> I've been using ditz for about a month now, and I have big pile of
> ditz issues.  Now I want to search through them and organize them, and
> I feel like I'm writing SQL queries except with long chains of greps
> and pipes.
> For example, I want to find all issues associated with a release that
> are assigned to a particular employee, filtered to just the issues
> that have a particular phrase in the description.
> Another example is that I decided to rename a release from 3.5.1 to
> "long-run".  Since all the issues use the release-name in their own
> issue file, all the issues that were assigned to 3.5.1 were now
> orphaned.
> A local sqlite database might solve a lot of these problems, but maybe
> there are other solutions as well, like just building index files.
> Also, I think it might be nice to use something like UUID to make
> unique identifiers for each issue, release, component, etc, and then
> use those IDs for references between them.
> Or if sqlite is no bueno, what about using one of those newfangled
> document databases like couchdb for storing issues?

More information about the ditz-talk mailing list