Moving this back to under review.
Will you please give us more information on your use case for this request?
You can't use multi-part key in a navigation property. We certainly DO support multi-part PKs (see Northwind OrderDetail which has an OrderID and a ProductID).
Either property of a multipart PK can be autogenerated.
And if you don't like what we do, you can create your own keygeneration strategy and make it yourself. Breeze has an extension for that.
Consequently, not sure what it is that you want to do that we can't do ... unless it is navigate w/ two-part key ... in which case ... you'll have to write your own navigation property to do that.
UPDATE: I'm informed that you can pass the entity class directly to the breeze metadata registration method today. In what ways is that inadequate? What do we have to change to satisfy your user voice request?
This will **not** happen for two reasons:
1. It would be a profoundly breaking change as `entityAspect` is one of the most widely used properties in the product.
1. **It wouldn't help**. The `entityAspect` is only one of many entity properties that result in circular references and stack overflows. Most navigation properties do it too.
1. The `ng.equal` "deep equality test" is inappropriate for breeze entity comparison as there are just too many values in a typical entity for this to perform well.
1. I don't understand why you'd want that anyway when object reference equality will do for most scenarios I can imagine. Remember that the entity object is mutated in place when breeze updates its values from, say, a re-query or a save.
I urge you to take a different approach to watching a collection of entities. I'd like to know what you're trying to accomplish.
Of course I could be missing something big. It would have to be gigantic for us to even consider such a change.
I won't let it get out of sync with BreezeJS core! But I agree that it belongs in core and will argue for that outcome with your help (and anyone else who votes for it).
To accelerate the development of this particular feature we are seeking user support through crowdfunding.
Want to learn more? Send us an email at firstname.lastname@example.org and we’ll send you details on how you can participate.
Thanks for helping us make BreezeJS the best open source project on the planet!
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.
@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 a big fan of this suggestion.
While that is true, if $scope.results = data.results fails you have much bigger problems. The app should come crashing down around your ears. My rule is "only catch an error if you know what to do with it".
Love this idea. Why not start it yourself? We'd be happy to contribute
385 votesunder review · 21 comments · 1. BreezeJS Feature Suggestions · Flag idea as inappropriate… · Admin →
All - very definitely want to explore SignalR and socket.io and Ajax working together in a Breeze app
@michael - the HTTP back-end is pluggable. It's called the 'ajax' adapter. We do have to show how to replace the jQuery implementation.
We often need to know quickly about backend changes and we are convinced (rightly or wrongly) that we shouldn't poll. SignalR is a great option ... for notification. However, I am not convinced at present that SignalR should deliver the entities to the client let alone update the client cache. I am more of the opinion that SignalR should tell the client about changes ... and let the client decide what to do about that. THEREFORE, while I'm eager to see an example of a Breeze client working collaboratively with SignalR notification, I don't feel that Breeze itself should incorporate this feature. It would help immensely if you would share your thought on Notification vs. Cache Update.
Quick update on this request:
We’re looking at being able to mark this as complete within the next couple of releases.
In my experience, async validations rules require such different treatment that they imay be impractical to implement them along side the synchronous validation rules we have today. Validation rules are often used to decide whether a process/workflow can go forward or not. The processes/workflows that consult those rules are generally not written to wait. For example, the Breeze EntityManager.saveChanges does synchronous validation and will not wait. Perhaps there is a way to change that without breaking existing applications. I would favor this proposal **if we plumbed asynchrony consistently throughout Breeze validation processing and provided some way of detecting when async validations are in flight**. Until then, you are better off implementing asynchronous checks (such as uniqueness tests) directly in your validation logic rather than through Breeze. In sum, it's worthy of review in the context of these broader design and implementation implications.
35 votesunder review · 14 comments · 1. BreezeJS Feature Suggestions · Flag idea as inappropriate… · Admin →
@bap Just to be extra clear: the controller METHOD returns IQueryable but what goes to the client is JSON DATA ... the result of server-side execution of the IQueryable. The IQueryable itself never leaves the server.
@bap You made the argument against including the UserID in the query from the client. it is useless from a security perspective. So don't bother. No, whatever extra filtering you do on the server stays on the server. It is not communicated to the client. There is nothing to spoof. The client's filter criteria are ANDed with the server's so the client can't expand the query. Now it doesn't hurt (belt-and-suspenders) if you want to see if the client tried to mention UserId. You can actually do that pretty easily simply by applying a RegEx to the request text ... which you have access to within any Web API controller method. But I'm not that paranoid :)
The logged in user is available to you on the server now. It should be in your identity that is in the `IPrincipal` (`System.Threading.Thread.CurrentPrincipal`). If you didn't put the `UserId` in the identity during your authentication step (which I recommend), you should be able to use that identity to acquire the `UserID`. The ASP.NET SPA Template and both Breeze SPA Templates illustrate this technique (they use the Web API controller's `User` property which is just a wrapper around `CurrentPrincipal`); all of them filter the TodoLists by `UserId`. So I don't think there is an action item for Breeze.
I understand the interest in QueryInterceptor. What is a ChangeInterceptor? Isn't that covered in the BeforeSave... methods described in http://www.breezejs.com/documentation/server-side-interception ?
The QueryInterceptor is an interesting challenge. You can write one today by taking over the ODataActionFilter ... that's a natural interception point. Once you were in the pipeline, what would you like to do? Examine the query string (easy). Examine the retrieved entities, including the ones tucked in by $expand (harder and potentially non-performant). Tell us what kinds of things you would do in your interceptor.
Yes, Ed, please do. Years of experience tell us this is not as obvious as it seems at first. So many options and thwarted expectations await. We have some of this in our DevForce product (see Query and Merge strategies); we didn't port it over to Breeze (yet) because we are not convinced that people know what they want. An essay from you would be welcome.