Ward Bell

My feedback

  1. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    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.

  2. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    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?

  3. 24 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    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.

  4. 5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    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).

    Ward Bell supported this idea  · 
  5. 926 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    19 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →

    To accelerate the development of this particular feature we are seeking user support through crowdfunding.

    Want to learn more? Send us an email at breezeadmin@ideablade.com 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!

    Ward Bell commented  · 

    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.

    Ward Bell commented  · 

    @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.

  6. 128 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    I am a big fan of this suggestion.

    Ward Bell supported this idea  · 
  7. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    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".

  8. 44 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    Love this idea. Why not start it yourself? We'd be happy to contribute

  9. 385 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  21 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    All - very definitely want to explore SignalR and socket.io and Ajax working together in a Breeze app

    Ward Bell commented  · 

    @michael - the HTTP back-end is pluggable. It's called the 'ajax' adapter. We do have to show how to replace the jQuery implementation.

    Ward Bell commented  · 

    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.

  10. 50 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell shared this idea  · 
  11. 16 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  6 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    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.

  12. 35 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  14 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    @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.

    Ward Bell commented  · 

    @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 :)

    Ward Bell commented  · 

    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.

    Ward Bell commented  · 

    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.

  13. 22 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  0 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell shared this idea  · 
  14. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  0 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell shared this idea  · 
  15. 14 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  3 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    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.

  16. 20 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  2 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell shared this idea  · 
  17. 11 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  0 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell shared this idea  · 
  18. 50 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  0 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell shared this idea  · 

Feedback and Knowledge Base