DynamoDB Items no longer support dict-like access

[Chris Moyer]

I was just upgrading to the latest version in git, and noticed that a recent commit has broken the "dict-like" access that DynamoDB Items use to have. For example, this no longer works:

>>> item = table.lookup("foo", "bar")

>>> item['dynamo'] = "db"

>>> item.save()

Previously this had worked just fine, but now you have to do this:

>>> item.put_attribute("dynamo", "db")

This is much less "dict like", although it does provide additional flexibility. Is there any reasonable way to restore dict-like access? I started working on generating a __setattr__ function, but there's a lot to do there to prevent the initial loading from coming in through there. Still, I think that would be worth while to restore this functionality.

Does anyone have any reason why this wouldn't be a good idea?

--
Chris Moyer

[Andy Davidoff]

This isn't new behavior. I was going to propose fixing this in IRC; wasn't sure if there was a reason it didn't work the way you suggest. One gotcha is that setting new values on key columns is a little tricky -- do we delete the old record? Raise an exception?

An alternative implementation might be to only queue put_attribute() for Item.update().

/mobile

[Mitchell Garnaat]

This thread:

https://github.com/boto/boto/issues/486

has some of discussion around this.  I'm definitely open to suggestions but it is kind of tricky issue.

Mitch

[Chris Moyer]

It's actually relatively simple to implement the __setitem__ and __delitem__ functions, the only complicated bit would be that technically if it's a list it would need to override the return value of a list to handle updating that directly. I'll check in what I have for __setitem__ and __delitem__ once I'm sure it passes all the layer2 tests.

--
Chris Moyer

[Andy Davidoff]

There's another problem you might want to look at while you're in there; currently the code below doesn't function as you might expect:

item.put_attribute('fruits', set(['apple','pear']))
item.add_attribute('fruits', set(['banana']))
item.save()

The attribute update queue is a currently a simple dict and doesn't retain prior updates. My vote would be to either enhance the update queue to handle multiple updates, raise an Exception, or eliminate the queuing altogether.

On Mar 5, 2012, at 4:45 PM, Chris Moyer wrote:
> It's actually relatively simple to implement the __setitem__ and __delitem__ functions, the only complicated bit would be that technically if it's a list it would need to override the return value of a list to handle updating that directly. I'll check in what I have for __setitem__ and __delitem__ once I'm sure it passes all the layer2 tests.

--
Andy Davidoff
disruptek.com
1-877-DISRPTK

[Chris Moyer]

I had looked at that problem too. This specific use-case seems pretty straight forward, if you do a put then an add,you'd expect that add to update the values you already put, but if you reversed that:

       item.add_attribute('fruits', set(['banana']))
       item.put_attribute('fruits', set(['apple','pear']))

       item.save()

Then what should be done? I'd say this literally means that it should be ['apple', 'pear'], but not include 'banana'.

In your example, however, it should contain all three. 

I think that's a relatively straight-forward fix if that sounds like the correct behavior. 

--
Chris Moyer

[Andy Davidoff]

That's right; note that ADD is also used for adjusting integers with the same state semantics.

On Mar 6, 2012, at 5:15 PM, Chris Moyer wrote:
> I had looked at that problem too. This specific use-case seems pretty straight forward, if you do a put then an add,you'd expect that add to update the values you already put, but if you reversed that:
>
> item.add_attribute('fruits', set(['banana']))
> item.put_attribute('fruits', set(['apple','pear']))
> item.save()
>
> Then what should be done? I'd say this literally means that it should be ['apple', 'pear'], but not include 'banana'.
>
> In your example, however, it should contain all three.
>
> I think that's a relatively straight-forward fix if that sounds like the correct behavior.

--
Andy Davidoff
disruptek.com
1-877-DISRPTK