0

In my spa I need to send a complex object tree to the client and let the user fill in his data, before the entities can be saved in the database. So the entities do not exist in the database at that moment. The object tree is constructed in memory on the server and simply fetched by a call to breeze.EntityQuery.from("ComplexeObjectTree"). The entities a bound via knockout to a web form. The user than enters the required data first, before he can push the save button. Some of the entities properties in the form are optional and have default values. If the user doesn’t change these properties, beeze will not detect any changes and will not put its owning entities into the change set. They are marked unchanged but their id values are still -1 (not saved yet). But the database save can only be executed successfully, when all entities in the object tree including their relations have been send to the server (to respect database constrains). The save operation should result in one or multiple insert statements, also for those entities that have not changed on the client, but are new to the database (id==-1). How can I handle this use case? Shouldn’t all entities with primary key id==-1 marked as Added and be part of the save change set by default?

Any help is very much appreciated,

Andreas

GETah
  • 20,922
  • 7
  • 61
  • 103
AndyK
  • 117
  • 1
  • 7

3 Answers3

1

Typically you would create the entities on the client and not on the server. That way the entities are new and would be saved in the save method.

Since the entities are coming from the server and they aren't being changed on the client, there is no reason for the server to do anything with them when they come back since they are in the same state as when they left.

So create you new entities on the client and then call save changes.

Bryant
  • 8,660
  • 1
  • 33
  • 53
  • Ok, that’s a valid option and we thought about it before. But we decided against it because than we have to start implementing major parts of business logic in to the UI layer. And I think this is not a good idea because of maintenance and security reasons (just think about changing the database model). Another reason is that a lot number calculation is going on in our business logic. Our experience so far is that massive calculation in java script and in c# always produces different results. C# is the only place where we want to do calculations - hence businss logic – AndyK Jan 25 '13 at 16:41
  • I think I could handle the use case, if breeze offers an generic way to get all entities in the cache of the client before save which key is equal to -1. Than I can simply set its state to Added and will become part of the change set. – AndyK Jan 25 '13 at 17:11
  • A few points. (1) Your model is still in your business layer on the server and comes down via metadata, so you aren't moving business logic. (2) For security it doesn't matter. Any malicious client can edit/add what they want in javascript, you *have* to validate either way on the server. (3) You can still do calculations on the server (via web service or on save). – Bryant Jan 25 '13 at 17:45
1

Let's do it your way and accept your claim that the object graph must be constructed on the server. If I understand properly, you are offering the user an opportunity to tweak some of the values you generate on the server before committing them to permanent storage. Sounds like a fine plan.

"ComplexObjectTree" does NOT have to be an entity graph. It can be an arbitrary data object. It could still be a CLR type but it wouldn't be (or contain) objects described in metadata nor would they be known to EF or to the Db. This object graph exists simply as info that drives construction of the real entity graph on the client. It has all the hard-to-calculate values in it that you don't want calculated on the client ... like the answer to the meaning of life and who wins the Super Bowl this year.

Your query returns this object with data but no entities in it. The querySuccess callback, CreateComplexTree(data), will make the entity graph on the client out of this data.

The entity graph will be composed of entities understood by the Breeze client, thanks to metadata. Unless you have an objection, these entities are also understood on the server and are ready to save and query like any other entities (you can work around that assumption if false ... but let's work on one problem at a time).

So you're all set. You walk your data graph, creating the entities as you go. When you see (-1) in the data, you know to create a new instance of the type. Copy the data into the entity initializing object which is the second argument in manager.createEntity('Foo', {...}). There's no business logic here - no calculation - just the monkey-work of copying.

I can't tell if EVERY object within the graph is to be inserted or only some of them. Maybe some of them are pre-existing entities that are unchanged unless the user changes them too. No biggie. You can follow the same approach to construct "Unchanged" entities on the client with a line like manager.createEntity('Bar', {...}, breeze.EntityState.Unchanged).

Now you have a proper Breeze entity graph, ready for binding, navigating, and saving. If the user loves it just the way the server created it, she presses the [Save] button, Breeze finds all the changes in the entity graph, and off they go to the server.

As Bryant observes, you can't really trust the client. You'll want to walk the graph to validate it. But that's true regardless of your methodology.

Hope this helps.

Ward
  • 17,793
  • 4
  • 37
  • 53
  • I full understand your approach. But I think there could be an easier way: Assume all entities on the client map to EF entities on the server. And assume further that all these entities already exist in the database. In this case I can safely create my object graph on the server from these EF entities and fetch it directly to the client as breeze entities and bind it directly to the form, without any recreating logic as you suggested. Any changes will be handled perfectly by breeze! What I don't understand, why is this not possible with newly created objects on the server?... – AndyK Jan 25 '13 at 21:12
  • ...I think the problem here is that breeze assumes that all entities coming from the server are existing and unchanged. I think the notion of “new” or “Added” is missing here, when fetching entities from the server. – AndyK Jan 25 '13 at 21:13
  • Yes, **Breeze assumes all entities coming from the server are existing and unchanged**. Those are essential semantics of the way Breeze works, OData works, Ember.Data works, RIA Services worked ... and every other entity-oriented system known to me. We are unlikely to change those semantics without a super compelling reason to do so ... especially when a perfectly reasonable workaround exists as I have shown. Here's another approach: give the "new" entities unique IDs and conjure some other way to detect that they are new. Then retrieve them from cache and change their EntityState to Added. – Ward Jan 26 '13 at 00:48
  • What isn't allowed ... will never be allowed ... is two entities in the same cache with the same key. Nor will we assume that an ID=-1 means anything; we don't know your ID numbering scheme. – Ward Jan 26 '13 at 00:51
  • Thanks Ward for your extensive help, and I can live with the suggested workarounds(!). But I am still thinking that this feature would make a lot of sense for Breeze. Just arguing that this feature is missing in other libraries as well doesn’t convince me. And I can’t see any technical problems implementing it. Your second approach, setting the EntitySate to Added upon some unique Id is very good. But as I was trying to implement it I couldn’t find entityAspect.setAdded(). After looking in the source code I found the implementation. But it was commented out in entityAspect.js line 550…? – AndyK Jan 26 '13 at 10:23
  • Holy Smokes! You're right that setAdded has been removed (or was never there)! I will find out why and whether we plan to "restore" it. Without it, the logic a little trickier. You essentially must (a) create a new entity,(b) copy the simple data property values from the incoming 'fake' entity, (c) remove the 'fake' entity. Or you could cheat (this is JavaScript) ... but I don't want to say how. We'll get back to you. – Ward Jan 26 '13 at 18:16
  • Does it make sense to accommodate queried entities that arrive from the server in other than an official, unchanged state? Can you get some votes for that? In ten years I've never been asked for this feature. Everyone expects them to be unchanged; should they now have to check? The additional complexity to support this ... both in Breeze and, more importantly, for the unwary app developer ... would have to be justified by demand. We'll listen if you can drum up that demand. For now the cost of this feature clearly outweighs the potential benefit. Happy to be proven wrong. Thx for the idea. – Ward Jan 26 '13 at 18:23
  • To be absolutely clear, we understand and appreciate your motivation and the request. Such feedback is vital to us and the future of Breeze. Although we are unlikely to pursue your suggestion unless it garners a great deal of support, we are grateful that you made that suggestion and took so strong an interest. We hope the alternative workaround serves you well. – Ward Jan 27 '13 at 06:48
0

Bryant is entirely correct is his answer. This answer is simply to get clarification.

Not entirely sure I understand the question but just to be clear the breeze EntityManager does not support multiple entities of the same type with the same 'key' (i.e. -1 in your case). It treats all entities of a single type with the same key as being the 'same' entity.

It sounds like what you want to do is retrieve a bunch of 'fake' entities into the entityManager and then conditionally convert a few of them into 'real' new entities' and save them causing these records to be added to the database. Is this what you are trying to accomplish?

Jay Traband
  • 17,053
  • 1
  • 23
  • 44
  • Yes. If you create a entity on the client Breeze assigns -1 to the pk. If you create two persons entities on the client you have two entities both with pk == -1 and state Added. – AndyK Jan 25 '13 at 19:44
  • Actually, if you create two entities with autogenerated pk's the first should have a pk of -1, the second will have an id of -2. The EntityManager will not allow two entities with the same key to be added or attached to it. – Jay Traband Jan 29 '13 at 20:25