JayData one to many projections

Question

I want to use jaydata JSLQ (JavaScript Language Query) to flatten a list of Post with one-to-many PostData into my ViewModel

My EF Entity looks like this:

public partial class Post
{       
    public Post()
    {           
        this.PostData = new HashSet<PostData>();           
    }

    public int Id { get; set; }

    public virtual ICollection<PostData> PostData { get; set; }
}

My database contains these records:

Table: Post
Id;...
1;...

Table: PostData
Id;PostId;FieldType; FieldValue
1; 1;     10;        "foo"
2; 1;     12;        "bar"
3; 1;     34;        "blah"

I want my view model in the client to look like this:

{id:1, title:'foo'}

That means, i want to put a filter on PostData that returns only FieldName==10, and i want to flatten that to a simple object.

How would I do that?

context.Posts.toArray(function(posts){console.dir(posts);})

returns an array of post objects. what next?

Hi Stefan, could you paste the definition of your JayData entities? — Peter Aron Zentai, Jun 28 '12 at 10:14

score 1 · Answer 1 · answered Jun 28 '12 at 11:15

1

This is achieved witht he SelectMany() function in EF and on this approach is not yet supported by JayData. You can however achieve the same output with directly querying aganst PostData and filtering on Post attributes.

context.PostDatas
  .filter( function(pd) { return pd.FieldType == 10 } )
  .map( function(pd) { return { 
                  PostID: pd.Post.Id, 
                  PostDataId: pd.Id, 
                  Title: pd.FieldValue }})
  .toArray( ... )

answered Jun 28 '12 at 11:15

Peter Aron Zentai

11,482
5
41
71

Thanks for the answer. Good to know that this does not work (yet?) . Your solution is a workaround that might work in certain cases but when it comes to denormalizing a list of posts to a simple list of viewmodels (post.title instead of post.postdata[0].FieldValue ) it becomes a bit unhandy. – Stefan Jun 30 '12 at 09:49
I could not quite catch what you meant. To me the problem in fact arises from the way the Post and its content the PostData is formulated. Namely that the entity is stored serialized in a name/value list. I know why this approach seems unavoidable (I have some cms background) but to my experience it always fires back. You lose the ability to use indexes and also the type metadata information. To store dynamically typed information sql may not be the best way. – Peter Aron Zentai Jun 30 '12 at 12:36
What I mean: what you in fact need is a store that lets you define entities on the run, and later on, it let's you to dynamically extend those entities without losing data. Do I see it right? My assumption is that the addition of a new field(type) is rarely if ever followed by the modificion of the c# code. – Peter Aron Zentai Jun 30 '12 at 12:48
I do see the point of switching to a nosql approach ("not only" or "no, not at all") - we will consider that option, we need to investigate though because relational database does have some advantages. for me it was important to find a a first solution to the problem so that we can deliver data to the client (javascript), later we will refactor the serverside. thanks for your comments! – Stefan Jul 01 '12 at 11:09
We have been this same situation: we needed something dynamic enought to be able to accept even a new entity type on the fly (without even rebooting/etc). Also we wanted something that could provide those RELATIONAL features that everyone really needs: like groups by, sums, etc. We think we just found this in MongoDB and a JayData provider is on the way for this. – Peter Aron Zentai Jul 01 '12 at 12:46

JayData one to many projections

1 Answers1