Ward Bell

My feedback

  1. 182 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  7 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    We actually have it! We should publish it.

  2. 258 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    15 comments  ·  3. Breeze Server Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    On our radar. Note that EF7 is barely RC1 and we know that RC2 has significant changes. We're treating RC1 as a beta and holding our fire until things solidify (especially in EF7).

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

    @ThomasMueller We are aligned.

    Ward Bell commented  · 

    I don't think it's a silly at all.

    First, it's an observation ... an observation that calls attention to the "silver bullet" affliction which pervades the developer community. Who wouldn't want to know if going async helps or hurts performance under what scenarios?

    Second, it's not an argument against adding the async signature. We need to do add an async API and will add it so that you, the developer, have a choice.

    Third, it is an argument for retaining the sync API, again, so developers have a choice.

    Fourth, while there *may* be relational dbs that scale, they are not many and not many breeze-using companies can/will run their databases in Amazon RDS any time soon (if ever).

    WE WILL add an async API. I'm just calling attention to an important caveat.

    Ward Bell commented  · 

    @Thomas - appreciate your perseverance. We will do it ... because the community wants it ... not just because I dropped it in the "ideas" box ;-) It's really only a matter of when.

    Ward Bell commented  · 

    @Thomas - That is a compelling case.

    Not sure that you absolutely need `AfterSaveEntities` for this purpose. You can always wrap the entire business of saving **in your own async `SaveChanges` method** and call into the `ContextProvider` synchronously from inside that wrapper. Then, when `ContextProvider.SaveChanges` returns (synchronously), you can call `await WorkflowInvoker.InvokeAsync()`.

    My point is that you probably don't have to invoke the WF at all from inside `AfterSaveEntities`. You only really need `AfterSaveEntities` if you want to manipulate the raw ingredients of the `SaveResult` before they are produced, perhaps within a distributed transaction.

    BUT, you really shouldn't have to think about all this. You should have the async signatures for

    * `ContexProvider`

    * `GetDbConnection`
    * `OpenDbConnection`
    * `CloseDbConnection`
    * `BuildJsonMetadata` // need an async `GetMetadata` too
    * `SaveChanges`
    * `SaveChangesCore`
    * `BeforeSaveEntities` // but NOT `BeforeSaveEntity ... keep that synchronous
    * `AfterSaveEntities`
    * `BeforeSaveEntitiesDelegate` // but NOT `BeforeSaveEntityDelegate ... keep that synchronous
    * `AfterSaveEntitiesDelegate`
    * `HandleSaveException`

    * `BeginTransaction` ???
    * `SaveWorkState`

    * `BeforeSave`
    * `AfterSave`

    May have to think about async key generation too.

    You see that this is not a trivial evolution, especially when you know that we have to write the async tests to go with this substantial API expansion.

    Ward Bell commented  · 

    I think @giles may have a use case but I don't understand it well enough. Perhaps he (or others) can help me grasp why lack of async support is a blocking issue.

    Ward Bell commented  · 

    Not yet. We have a few more important items in the queue that are ahead of it.

    While I really do want us to support async Web API, if we're honest about it, this is a performance enhancement that delivers value only when you have a lot of people hitting the server. Much as I want to believe that a Breeze app is running into such scaling problems, I lack the evidence for it at this time.

    If you have can give me some evidence or make the case for escalating this feature, we'd sure like to hear about it.

    Ward Bell commented  · 

    I'll try to find out where it is in the schedule

    Ward Bell commented  · 

    @Giles - while I heartily agree that we should write an async version of these components soon, it is pretty cheeky of you to claim that WE broke your code when it was YOU who changed your code to be incompatible with Breeze. ;-)

    Ward Bell commented  · 

    Nothing yet. It's on our list but we have nothing to show yet.

    Ward Bell commented  · 

    No news just yet.

    I am curious about your interest in this matter. Enabling async will improve performance in some high volume circumstances but shouldn't be standing in your way during early development. When do you think you will need it and why?

    Ward Bell commented  · 

    We're planning it now. Will be back with a "when" when we know ourselves.

    Ward Bell shared this idea  · 
  4. 338 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    11 comments  ·  1. BreezeJS Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Ward Bell commented  · 

    Sorry. Just have not got to it. There is a work around (not great) and we're working higher priorities. This is an open source project. We'd welcome your attempt at it and a PR.

  5. 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  · 

    FWIW, I have long felt we made a fundamental error in making entityAspect a property. It should have been a getter method. Too late now though.

    Ward Bell commented  · 

    Thanks for the deets. I'll take a look at the code you linked

    I hasten to add that there is an easy and performant way to detect changes ... listen for property changed, either on the entity itself or on the `EntityManager`.

    That's where I'd go and then to see how to drive ng-firmly from that ... if that's possible.

    Events always beat watches. The problem with events is setting them up. Breeze does that for free.

    I will look at your links soon.

    Thanks for the dialog.

  6. 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 supported this idea  · 
    Ward Bell commented  · 

    UPDATE: I'm a TypeScript idiot. You can get the prototype from a TS class quite easily. I'll bet it's the same in ES6.

    Here is some TS that you can try in the playground (http://www.typescriptlang.org/Playground) that proves it:

    ```
    class Foo {
    private _baz = 'original _baz';
    get bar() { return true;}
    get baz() { return 'first baz';} // type-safety placeholder; will be redefined
    }

    // You CAN get the prototype from the class!
    var x = Foo.prototype;
    console.log(x);

    // baz has no setter at this point
    let foo = new Foo();
    console.log("foo.baz1:" + foo.baz); // "first baz"
    foo.baz = "new value";
    console.log("foo.baz2:" + foo.baz); // still "first baz"

    /* redefinition has a setter and is no longer configurable */
    Object.defineProperty(Foo.prototype, "baz", {
    get: function () { return this._baz; },
    set: function(value) {this._baz = value;},
    enumerable: true,
    configurable: false
    });

    // redefine `foo` with new version
    foo = new Foo();
    console.log("foo.baz3:" + foo.baz); // "original _baz"
    foo.baz = "new _baz";
    console.log("foo.baz4:" + foo.baz); // "new _baz"

    ```

    Ward Bell commented  · 

    Your comment counts.

    You can add methods and properties to the ctors today. You don't have to add them to the initializer ... and I don't know why you would.

    There is only a potential problem if the property has a **setter** and you do NOT want breeze to track it as an "unmapped property". Even then you can add such a property to the ctor AFTER registering with breeze client `MetadataStore`.

    BTW, adding properties to a class later is kind of tricky in TS/ES6. The class constructor is not exposed by default so you can't grab it to add to the prototype.

    Fear not, grasshopper! You can add a static method (in TS anyway) that exposes the ctor ... and mess with it anytime. I have no idea if the same game is viable in ES6.

    I'm thinking out loud here. Given that Breeze has to rewrite the ctor anyway (in order to inject its goodness), I'm not quite sure how we're going to do this with TS or ES6 classes. We need that prototype.

    Personally, when it gets funky like this, I'd chuck the class. This nonsense is one (among many reasons ... mix-ins being another) why I don't like classes and wish they had never been introduced. I was doing just fine with prototypes and I don't get the value of classes ... whereas the harm I see. Apparently I have company in Douglas Crockford.

  7. 113 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  · 

    Will do ... for sure when Ng2 is no longer alpha. You're welcome to contribute a suggested bridge for the alpha Angular 2 and tell folks about it.

  8. 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  · 

    Not to my knowledge. The execution of the LINQ query occurs outside the controller method. There is no way to inspect the results.

    The only way I know to intercept the results is to execute the query yourself after applying the client's query specification ... which is no easy task.

    .. or to write a custom Web API filter (for example, modify the JSON serialization filter with a custom Json.Net serialization interceptor) ... which seem like the wrong abstractions to me and would be no easy task either.

    I've been thinking about an option on the BreezeEnableQuery attribute for calling back into some method in your controller that could post-process the results before sending them out of the controller, toward the client (that is, onward to the filters). I have gotten no further than speculation.

    Ward Bell commented  · 

    You can get the query string from the URL programmatically with code like this:

    var allUrlKeyValues = ControllerContext.Request.GetQueryNameValuePairs();
    string filter = allUrlKeyValues.SingleOrDefault(x => x.Key == "$filter").Value;

    What you do with it is another matter.

  9. 929 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  · 

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

    Ward Bell commented  · 

    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 Bell commented  · 

    @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 Bell commented  · 

    @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

  10. 5 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  · 

    We hate to disappoint. We just don't know what to do about it. We don't understand the scenarios in which this feature would be beneficial.

    For example, what do you do in a form when the user "pages" away while the async validation is in-progress? Should the user be allowed to leave or not? How would the user return if there were a problem?

    How should saveChanges work? At least saveChanges is already async so we could plumb async validation through it. But do you process the save before the async validation returns? I think not. It's not acting as a validation then and if the server rejects it, you now have two competing validations for the same rule. But maybe you'd expect something different?

    My point is that the problem is not as simple as firing off a validation. You have to work through the consequences. I don't know what the right thing to do is in all scenarios for all apps. I don't know where to put the hooks so that we can offer a facility that everyone can use appropriately.

    We're not talking about a "fix" here. This needs real thought. We wouldn't know what to implement until we had good answers.

    On the other hand, it isn't difficult for you to write application-specific async validation logic that does exactly what you want. Post your scenarios to StackOverflow and we can all work through this together. Maybe the proper implementation of a feature will become apparent when we've worked through some real use cases.

  12. 106 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 shared this idea  · 

Feedback and Knowledge Base