0
votes

The admins for my application can make extra properties for the userprofiles. So UserA can have 1 Cellphone number , while UserB can have 5. Or UserA can have a Creditcard number while UserB doesn't have any.

I want to make this work with Azure Table Storage. I'm making generic entities and inserting them into Table Storage.

I know every entity/row can only have 255 filled in properties ( Partition Key, Row Key, Timestamp and your own properties.) In my situation there is a high chance there will be more columns but a very very small chance 1 user will actually use 255 properties.

Now here is the problem, when the user reads his entity all the other properties that he doesn't use will be 'm:null="true'.

As you can see he still takes the extra properties he doesn't need. I can of course ignore them in my ReadingEntity Event but it's still overhead right? Imagine you want to get the profiles of 100 users and you have like 500 columns. There will be a lot of useless data in that xml file & network traffic.

Is there any way to ignore those null and don't send them back at all? Instead of sending them back and marking the column as null?

enter image description here

3
Perhaps you'd like to split that into two tables? One for the master (i.e. person) record, and another for the details (phone numbers, addresses etc.). Unless you always want all the details when you query a list of people (most likely not), you're incurring unnecessary overhead (and costs).Stephen Chung

3 Answers

3
votes

And are you using development storage? Make sure to try this against real cloud storage... dev storage saves an actual schema and may be applying properties from other entities to the one you're trying to read. – smarx Jul 5 at 17:28

This was the solution

2
votes

When you are saving an entity, are you saving these extra properties (with null value) as well? As far as Cloud Storage is concerned, if you don't provide an attribute while saving an entity, you will not get that attribute back when fetching entity. However working with development storage is another story all together. There if you have saved an entity with say 3 custom attributes and another entity with 5 custom attributes. When you fetch the entity, you will get all attributes back.

1
votes

The only way you will see null things returned to you is if you saved them to begin with. I would check again your generic entity persistence code or your generic entity itself. It must be the case there are null values being sent for saving. Since there is no schema in table storage, it is impossible for it to to send values for fields it doesn't know about. Fiddler will show you for sure on a save.