EntityExpressions: The heart of JayData

Author: Hajnalka Battancs May 1st, 2012

At a first glance, JayData is a data access framework that allows you easy and uniform access to a plethora of data sources. That in itself is a great help to many Javascript developers, but in its depth we had a much more ambitious goal than just that. We wanted a system that is easily extensible – we wanted to make your life as easy as possible if you wish to add a new, custom StorageProvider.

As you may have learned by now, the JavaScript Language Query (JSLQ) API allows the developer to describe their intentions in native Javascript calls and functions, our model system uses native Javascript types, and we provide a smart object model for CRUD operations. The possibilities in native code are virtually limitless, and creating mappings for it would entail building a small compiler for Javascript – a gargantuan task, something that should definitely not be part of creating bindings for a custom data access API.

That is why we essentially did that for you. The real strength of JayData is the way it represents the developer intention entered through the native Javascript API internally.

We’d like to show you how a convoluted, language native query becomes an ordered, straightforward expression over entities that a data access binding can handle with ease. Let’s start with this JayData filtering operation:

JS code expression tree

When a JayData operation is executed, first the framework analyzes the expression tree of the call, parsing it and creating a document model representation of the Javascript code in the form of a code expression tree.

This is what the code expression tree of the above filtering predicate would look like:

This representation is still a full, 1 to 1 mapping of the original code, and if needed, is accessible for the provider. However, for most uses, even though parsed and validated, this is far too complex for everyday use.

Entity expressions

That is why we go a step further, and using the system’s knowledge of the metadata, we analyze and translate the Javascript expression tree into a format that clearly states the developer intention over the data entity model, in the form of a very limited set of expressions such as equalities and  Here code errors and type mismatches have already been caught, language complexities removed and converted to a plain description of data access tasks.

This is what we call the entity expression tree, and is the main source of information that StorageProviders use to determine the necessary provider-specific operations.

Why this is invaluable (beside the obvious)

Javascript is a very flexible language. Instead of the above code, someone might write this, which is totally identical in its meaning:

This would cause severe changes in the JS code expression tree, as instead of a property access, now we have an array indexing expression. And this is just one example of the almost limitless variety of the language.

However, on the entity expression tree level, this code would generate the exact same tree that you see above.