Can wespecify short aliases for entities
Hi,
This is more of a EDM question I think, but I'll ask anyway. I'm an EDM noob so bear with me OK.
I've just built myself a very simple Astoria data service. A simple query returns the following response:
<?xml version="1.0" encoding="utf-8" ?>
<DataService xml:base="http://localhost:1156/wherewasi.svc">
<User>
<User uri="User[1]">
<UserID>1</UserID>
<UserName>Larry</UserName>
<LocationHistory href="User[1]/LocationHistory" />
</User>
<User uri="User[2]">
<UserID>2</UserID>
<UserName>Geoff</UserName>
<LocationHistory href="User[2]/LocationHistory" />
</User>
<User uri="User[3]">
<UserID>3</UserID>
<UserName>Sandra</UserName>
<LocationHistory href="User[3]/LocationHistory" />
</User>
</User>
</DataService>
The actual data elements in there consists of only 6 data values totalling 19 bytes of info and yet the whole reponse is 620 bytes. You can see that his is going to become a real problem when my data volumes grow.
What I'd like to do is specify short aliases for my entities and navigation properties (is that the right nomenclature?) so that User, LocationHistory, UserID, UserName become U, LH, UID, UN respectively.This would have a hugely positive effect on the size of the response.
So, is it possible to define what these things are called in the EDM? It'd be nice if the EDM wizard in Orcas asked us if we wanted to define aliases. Ah well...
Am I talking out of my behind here or does anyone else think this is a good idea?
-Jamie
Hi Jamie,
While there is no explicit mechanism in Astoria itself to do this, that's why it's nice to layer on top of the Entity Framework. You can use mapping in the entity framework to rename the fields to their short form. Of course, then you'll have to refer to them always using the short form (e.g. in queries, updates, etc.), but if compactness is a priority that is probably a reasonable trade-off.
Independently from compressing names at the schema level, note that since we go over regular HTTP you could use compression at the HTTP level. The client-agent can indicate that it can support compression in responses, and on the server you could use one of the add-ons for ASP.NET to support compression (they are usually ASP.NET modules). XML typically compresses really well, so it should help significantly with bandwidth utilization.
Pablo Castro
Technical Lead
Microsoft Corporation
Once you get into the point where you are talking about massive amounts of data, the "overhead" of the XML brackets and the start- and end-tag notation is going to be far more than the overhead of using entity names like "Cust" instead of "Customer". I've been in situations before where my performance needs were so high that I needed to trim the names of columns being transmitted over the wire... at that point I decided that XML was simply not going to do the job for me and I used a binary format.
This may just be a symptom of me not knowing what kind of app you're building, but from where I sit I don't see you gaining more in raw performance from shortening the names of entities than you lose in the productivity of having self-documenting entity names. If you're at the point where you need to nitpick entity names in order to squeeze out performance, then I have to agree with Pablo that using something like HTTP compression or maybe a different encoding format entirely (is JSON lighter weight than XML? I don't know....) is in order.
Kevin Hoffman wrote: