What is the status of this feature request? I know we have a workaround via http://breeze.github.io/doc-cool-breezes/presenting-many-to-many.html#livecode but it'll be good for BreezeJs to support it out the box. Please respond. Its been a 1.5 years since the last post. Thanks

@Ward We've managed to get along without m-2-m in Breeze since my last post, and we're successfully using Breeze for the many forms in our applications. Given, we're only scratching the surface of what Breeze can actually do, but so far so good. Keep up the great work!

@aaron - why is this a requirement? It's a really iff idea to begin with. You do realize that if you ever have to add even a single field to the junction table ... a timestamp ... anything ... then the whole m-to-m collapses and you're right back to a 3-part entity implementation: left - junction - right. It's an extremely brittle EntityFramework technique that I have always avoided.

When is it going to get implemented?

Any word on when/if the fundraising for m2m will begin? We're about to build out an entire phase of our app that requires it, and I'm afraid we won't be able to utilize Breeze (which would be awful, since we love it for everything else!).

$100-$200 is perfectly OK for me. This feature will save me a lot of time!!

I can assure you that we at IdeaBlade deeply appreciate the financial votes for a feature in amounts of any size. The act of opening your wallet sends a signal more powerful than a vote button. Thank you all.

Ward, Putting aside differences in philosophies as to whether or not m-2-m should be used, how much money are we talking about in order to 'motivate' this issue toward the finish line? There has been talk on this thread for a while (and A LOT of votes), so let's solidify this notion and see if we can't raise the dough. I'm new to Breeze, but I for one would be interested in contributing.

LOL! Okay, okay. Point taken. I hadn't looked at their code. Hell, I hadn't dug further than what they presented on their website.

I figured there was more to it, and the entity caching part makes a lot of sense. It's great that you have something to use as a guide.

@Brian - I have to leap to the bait about JayData. "Feature Matrix". Don't make me laugh.

They don't have m-2-m "figured out". They don't have relationships of any kind ... not in the Breeze sense.

They don't have entity caching or identity map. They don't have to maintain the creation and dissolution of relationships over time. JayData has nothing comparable to the ability to fetch the Orders now, fetch the OrderDetails later, and have something wire them together automatically.

The 'm-2-m' problem is quite trivial if you don't have to do anything but return an object with an embedded related-entity array handed to you by the server. Anybody can do that. That's not what your asking for.

You want Breeze to maintain a User/Roles relationship (linked by a hidden UserRole mapping table on the server) in the same way as Breeze today maintains 1-M relationships such as Order/OrderDetails.

Maintaining relationships among entities in cache is hard ... and there is nothing in JayData to reverse engineer.

There is something we can use as a guide: our own DevForce .NET product.

@Ward, thank you for the response. That helps us immensely with our API road map knowing that it will be there eventually. Difficult? It very well could be.. I thought maybe it could be inferred from the key information on entities that have keys and then related properties and their types that are passed in the metadata, but that feels far too easy, I'm sure I'm missing something... It appears JayData has m-2-m odata and Web API figured out according to their feature matrix, maybe it could be reverse engineered and serve as some inspiration. I might dig into the breeze code and see if I can come up with some ideas. Sooner is always better, would love to have it done before we get too much client buy-in on our API. Cheers...

@Brian LOL! I know I'm fighting a losing battle and have lost it in fact. We have it on our backlog to do. I wish I could say when it will be done. This is REALLY hard to get right. We know that because we've done it before. Looks like we'll be doing it again.

The offer of $$ is intriguing. Nothing like money to motivate. We might just pass the hat to get this done sooner. Cheers, W

So... Ward, while I appreciate your passion about m-2-m, and love breeze, for many what you profess is a non-issue. They have control over their m-2-m, and it will not change - ever. They simply need to have an object with an array of related objects. That is the way ORM works. That simple. And while you have valid points, I challenge the m-2-m is bad practice idea; mulitple requests and sending a unnecessary data over the wire is far worse on many more facets (poor UX, bandwidth, more code, ...). There is a reason this is the "most" requested feature. Lack of m-2-m is Breeze's Achilles heel (that and documentation is a bit light and incomplete). Sorry to sound harsh, but 2 years for a request with an order of magnitude more requests than anything else is not listening to your users.

If you need money to do it... There a 639 of us that I'm sure would pitch in. Put up a link.

Chris - take a look at the JsonResultsAdapter. It gives you access to the entity data as they arrive and before Breeze turns them into entities.

Note again that we still believe that using EF many-to-many is a serious design mistake on your part. We would support it anyway if it were easy. But the combination of BAD IDEA + HARD = NOT SOON. If you want to pay us to add it ... that could change its priority significantly. No one has made that offer yet. Therefore, I would not hold my breath on this one.

The data for many-to-many relationships comes down over the wire, but Breeze then removes that association. This is frustrating, as you can see the data there but cannot access it through the entity object. If there was some way to expose the data in the short term (even if you couldn't use it for full entity tracking) this would be useful.

Cannot query or do anything like sorting or grouping or get the firstItem, lastItem or put the where clause on n-n related entities is not realistic in real world application.

any news on this?

@sverre I appreciate that there is interest in this. I differ with you in one crucial part, however: the "junction" entity absolutely IS the EF way. IMO, many-to-many is a giant mistake in EF models because it is unmaintainable. The moment that the relationship needs a payload ... and it could be anything ... a tenantId, isDeleted, dateCreated, concurrencyColumn ... the many-to-many is broken and you HAVE to implement the "junction" entity. If you've build your app around the EF m-2-m and that urgent requirement comes in for the payload ... you are in a mad scramble to fix your app. I strongly advise that you .... and everyone ... avoid this construct from Day 1. You will thank me for this advice in the not-distant-future.

I am wondering how this feature is coming along? I know it is possible to get around this by exposing the junction tables, but it is not the EF way. In my current project this is the last hurdle. Otherwise I am very impressed with Breeze is working wonderfully,