Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Don't sweat it. Keep exploring. We are all learning.</p> <p>I don't know if it's better to put this in the ViewModel (VM) or in the entity. There is no intrinsic right answer. </p> <p>Let's assume you want it in the entity (because that's more interesting from a Breeze perspective). Next question: do you need it to be observable?</p> <p>You wrote "<em>it's a straightforward standalone result of a calculation and is only used for display purposes. Nothing can change on the page that will affect the result, it's already happened.</em>" That suggests that it need not be observable so you won't need a KO computed. Your most recent solution isn't even presenting it as a property; I'm guessing something in your VM is calling <code>getResult()</code>.</p> <p>This leads me to think that you might prefer registering a <strong>custom constructor</strong> and putting <code>getResult</code> on the prototype of that constructor:</p> <pre> var Game = function () { } Game.prototype.getResult = function () { var ours = 0; var theirs = 0; this.sets().forEach(function (s) { (s.ourScore() > s.theirScore()) ? ours += 1 : theirs += 1; }); return (ours || theirs) ? (ours > theirs ? "Won " : "Lost ") + ours + "-" + theirs : "No result"; } store.registerEntityTypeCtor("Game", Game); // ctor but no initializer </pre> <p>On the other hand, if you thought the scores could change and you wanted the screen to update as they did, you'd probably want to move the logic into a <code>results</code> KO computed. The <code>ourScore</code> and <code>theirScore</code> observables should keep the <code>results</code> computed up-to-date. I'm thinking out loud here, not having tried it.</p> <p>You would define that <code>results</code> computed in an <strong>initializer</strong> rather than the ctor. Why? Because KO observables must be attached to instances, not to the prototype. If you defined it within the ctor, Breeze might try to serialize and change track it. Better to tack it on to the entity in the initializer; Breeze ignores entity members added by an initializer.</p> <p>On further thought, maybe I'd keep the <code>getResult</code> method where it is in the prototype and write an initializer that added a ko computed ... like so (warning: not tested):</p> <pre> function gameInitializer(game) { game.results = ko.computed(function() { return game.getResults();}); } store.registerEntityTypeCtor("Game", Game, gameInitializer); </pre> <p>And now for the serious point: <strong><em>should this logic be in the dataservice</em></strong>?</p> <p>I would not have it in my <em>dataservice</em> for the very reason you state yourself. This kind of logic expresses concerns intrinsic to the model and has nothing to do with managing data access. It's OK to mush it all together in the <em>dataservice</em> in a demo. In "real" code one would factor it out into a <em>model.js</em> component (I think of <code>Game</code> as a Model component, not a ViewModel component) and load that script between the dataservice.js and the viewmodel.js script tags.</p>
    singulars
    1. This table or related slice is empty.
    1. POExtend entity or add ko.computed to return additional property in entity that is not in database
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USWard
    1. USWard
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COThanks for the input Ward, much appreciated. I can understand the more efficient javascript code used in the getResult function and I'll use that syntax in future. I don't, however, understand the benefit in putting the getResult function on the prototype. I'll still need to have the initializer and define the "game.result" property, won't I? In your code snippet there is no game.result otherwise. If I'm doing that anyway, where is the benefit in having the function on the prototype? Is it just to stop me having to pass in the "game" entity explicitly into the "getResult" function?
      singulars
      1. PO
      1. USTheMook
    2. COPutting the bulky logic on the prototype should reduce the memory footprint ... at least in principle. The prototype function is shared among all of the Game instances whereas if you added it in the ctor, each instance would have its own copy. Modern JS engines may optimize this away ... I don't know ... but that's why we move code to the prototype when we can. Don't get carried away by the syntax I used. It may not be more efficient. It's just easier for me to see the concepts when there is less syntactic noise (my style preference).
      singulars
      1. PO
      1. USWard
    3. COSorry! Just saw you answered this above.
      singulars
      1. PO
      1. USTheMook
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload