Azure table implementation

[MindFlavor]

Azure tables

An implementation of Azure Tables REST API using JSON instead of XML where possible. I strove to be aligned with the existing storage code so the usage is pretty straightforward:

err := cli.CreateTable(tn)
err := cli.DeleteTable(tn)

I could have mapped the entities to maps (map[string]interface{}) like it's done in the python Azure SDK but that would be awkward in golang: json and xml packages are able to handle custom structs using reflection so I did here too. For insert just pass the storage.TableEntity implementing struct and it will be marshalled automatically:

ce := &CustomEntity{Name: "Luke", Surname: "Skywalker", SomeDate: time.Now(), Number: 60, PKey: "pkey", RKey: "5"}

err := cli.InsertOrReplaceEntity(tn, ce)

As for unmarshaling you have to specify the type you are expecting:

entries, contToken, err = cli.QueryTableEntities(tn, nil, reflect.TypeOf(ce), 10, "")

Note that these methods store in Azure table rows (without hierarchy) so nested structs should not work by design.

There are more examples in the test files.

storage.TableEntity interface

type TableEntity interface {
    PartitionKey() string
    RowKey() string
    SetPartitionKey(string) error
    SetRowKey(string) error
}

Implement this interface to store your structs in Azure Tables.
This interface requires you to specify the partition and row keys as getter/setter. This way you can are free to represent the Azure Table primary key in your struct as you see fit.

table tag

The marshaler allows you to avoid persisting in Azure tables certain attributes. Just append the table:- (table minus) tag and it will be ignored. For example:

type CustomEntity struct {
    Name     string `json:"name"`
    Surname  string `json:"surname"`
    SomeDate time.Time
    Number   int
    PKey     string `json:"pk" table:"-"`
    RKey     string `json:"rk" table:"-"`
}

In this case the fields PKey and RKey won't be stored. This is useful because Azure Tables always require you to have the PartitionKey and RowKey fields so if you were to store PKey and RKey too you will end up duplicating the information.
The code will call your TableEntity.SetPartitionKey and TableEntity.SetRowKey methods during unmarshal allowing you to restore the ignored fields correctly.

Comments

The code is very poorly commented. Most methods lack the proper description. I will add them as soon as I can.

ToDo

• The biggest todo is to return the If-Match header in the Entity get methods. Without it you cannot use optimistic concurrency in deletes. The DeleteEntity method supports is anyway so it's just a matter to return it to the GetEntity callers.
• Better support for OData queries. Right now you can specify only the $filter param and you have to construct it by hand. Azure Tables also support the $select parameter for projection but I have not inserted the code here. It should be easy though. What would be harder is to implement the odata protocol. There is a project on that here (https://github.com/amsokol/go-odata) but I haven't looked at it yet.

[ahmetb]

hey @MindFlavor I just merged #298 which reads this from Client.HTTPClient (and defaults to net/http#DefaultClient). In this case you'll probably need to rebase your code on top of master and refactor this part sometime.

[MindFlavor]

Merged.

[ahmetb]

it still looks like this part is not addressed. can you just git fetch origin && git rebase origin/master and git push -f

[MindFlavor]

Well of course, I was merging from the wrong repo 😊 ... It should be ok now...

[ahmetb]

@MindFlavor you should still update this part to use c.Client. Please see the change in #298.

[MindFlavor]

Once again, sorry :-). Let's hope I got it right this time 😊

[MindFlavor]

Sorry @ahmetalpbalkan I missed your comment

@MindFlavor I just didn't understand this part: we call SetPartitionKey/SetRowKey only when deserializing from Azure Storage response right? There's no way it can be invalid. Users should not store user-domain data in PK/RK as far as I know. Even in the C# SDK, these fields are just strings and you're going to be given whatever server gives you, you can't error out in that case? :)

I'll fix it right away removing the error and push again :)

[MindFlavor]

I've also noticed something weird in Travis' test suite. As you can see from the last log:

table_test.go:263:
    c.Assert(entries[0].(*CustomEntity), chk.DeepEquals, ceList[0])
... obtained *storage.CustomEntity = &storage.CustomEntity{Name:"Test", Surname:"Test2", SomeDate:time.Time{sec:63594497276, nsec:347889129, loc:(*time.Location)(0xb75f40)}, Number:0, PKey:"pkey", RKey:"r0"}
... expected *storage.CustomEntity = &storage.CustomEntity{Name:"Test", Surname:"Test2", SomeDate:time.Time{sec:63594497276, nsec:347889129, loc:(*time.Location)(0xb7a2a0)}, Number:0, PKey:"pkey", RKey:"r0"}

The DeepEquals does not work as expected, it does not follow the loc:(*time.Location) pointer and compares the addresses instead (loc:(*time.Location)(0xb75f40) in one case and loc:(*time.Location)(0xb7a2a0) in the other). It should compare the Deep internal values instead :).
This is clearly a bug (and on my pc works correctly but... that's always the case of course 😊 )

To work around this I've removed the indirect time field in the tests for the time being. I think we should reinstate it sooner or later though (and that's why I had a separated testEquality method I think).

[ahmetb]

@MindFlavor do you ever use these error message/code fields in generating a human-readable error? perhaps we should return a typed-error that people can cast into and read these fields?

[cyonix]

Would be nice to see this pull request get merged in soon guys!!

[ahmetb]

Sorry for the delay here. We are okay with merging this, thanks a lot to @MindFlavor staying on top of this.
@MindFlavor there are still a few comments above, if you feel like addressing them I appreciate follow up requests. I will now squash this and merge.