OpenSourcery

I have a few longer posts that I want to write, but none of them are coming together in my head right now, so I'll put together a quick note about Prophet and SD, by Jesse Vincent and Chia-liang Kao. Prophet is a replicated, peer-to-peer database (I'm cutting its sales pitch short, see the website for more), and SD is a bug tracking system written on top of it.

I had looked at SD a year or so ago, and then forgot about it until I read a post by gugod describing how to use SD to interact with rt.cpan.org, through SD's helper script git-sd. This caught my interest, of course, because I use rt.cpan.org for all the CPAN distributions I maintain.

What makes SD interesting to me, at least more so than other local-storage ticketing systems like ticgit, is that it has adaptors ("foreign replica" classes, in Prophet terms) for several other bug tracking systems, including (as mentioned above) RT and Trac, both of which we use at work.

I like the idea of having tickets available right there with my repository, and I especially love not to have to switch contexts, fiddle with my web browser, etc., every time I finish one bug and I'm ready to move on to the next, but I don't have the luxury of telling all my coworkers that we're switching to some new ticketing system. The fact that I also get free disconnected operation is just icing on the cake. SD feels like git in this regard -- distributed, customizable, and able to play well with existing systems instead of needing a complete change-over.

Since reading gugod's post and getting excited about SD, I've tweaked git-sd a little, and pushed my patches back upstream. In particular, git-sd now defaults to using GIT_DIR/.git/sd for its replica, instead of requiring that you manually configure one, which streamlines the process of setting it up. I have plans for a few more things that I want to do before I use SD heavily:

• make it easy to store username and password per-replica
• give replicas a short name to refer to for push and pull, like git remote

SD and Prophet are relatively young, but so far almost all the problems I've
run into have been minor interface issues rather than big showstopping bugs.
Here's the only thing I'm aware of that might fall into that category:

<obra> soooo close to trac roundtrip too
<confound> which would be great for me
<confound> since we use trac at work
<obra> I have one crippling bug.
<obra> I just need a 4 hour block of time
<confound> what is it?
<obra> when you create a ticket in sd, push to trac and pull from trac, it
doesn't properly map the uuid
<obra> oh.
<obra> I know what it is now
<obra> (explaining problems)++

And now that Jesse has achieved enlightenment through explaining the problem to me,
I expect it'll be fixed quickly. So glad I could help! :)

Yesterday I wrote a plugin for RT which allows one to use the members in a group as the values for a custom field. This is useful because it allows for user-signoff functionality. The problem to tackle was specifying which group to use. The obvious answer was to use an attribute on the custom field. The custom field was passed into the plugin via an inherited method. I chose to override this method and capture the field so that I could grab its attribute.

The solution would have worked except that I assumed the method was not needed anywhere else, a very silly mistake in hindsight. So I fired up RT and sure enough it did not work as expected. Since my mistake was very silly indeed, it was easy to spot and correct. Following good practices, however, I decided to add an additional test that covered what I had missed previously.

If I had fired up RT as soon as I "fixed" the problem, I would have seen it working as desired and avoided a huge headache. Unfortunately, however, I did not fire up RT; I ran my tests instead. To my dismay my new tests were failing. I was sure I had done everything right, so I double checked:

* Field Created - Check
* Attribute added - Check
* Attribute exists - Check
* Using my class worked - Check
* Asking the field for its values - Fail

At this point I began to suspect a bug in RT, or incorrect documentation, because I was sure I had done everything correctly. I was right, too. It was all correct. The problem was that when I first started working on RT I had to add and retrieve attributes manually using the RT::Attribute class. However RT has an RT::Record class that most RT classes inherit from. Within this class are some methods for adding and retrieving Attributes on an object. Unlike me, RT used these methods.

I am not sure if my inexperience 6 months ago led me to miss them, or if they simply were not in RT at that version (we previously used 3.6, we now use 3.8) but for whatever reason when I first looked for them I did not find them, and have been doing it the hard way ever since. After a very long time of poking at every little thing trying to find my mistake, or an RT bug, I eventually found these methods.

I Added a test to retrieve the attribute using the RT method... no luck, test failed. So I looked more deeply at the methods. What I found made me slap my forehead. RT caches attributes when an object is created/loaded. As such I would crate my custom field and then my attribute, however since I did not use the method, the cache was not updated. Because of this very few components, if any, would be able to find it.

This cache issue is not one that ever would have come up during usage. Our system loads data such as attributes into the database well before the server is started, because of that they would be present. This is why firing up the app would have shown that it was indeed working. I was able to update my test, and now everything passes.

Lessons:
* When you think 'hey, that method would be useful, but there is none' take note to check every version update to see if it was added.
* If you know your application does caching, and you are not getting data you KNOW you gave it, make sure the cache is updated.