SteveB
My feedback
7 results found
-
2 votes
-
Entity creation: Initialise Foreign Key - Properties which are Nullable with Null (Currently it's 0)
19 votesAn error occurred while saving the comment An error occurred while saving the comment I think I agree with this suggestion -- even though there are a couple technical issues with the wording. First, I think you meant to say 'nonnullable' instead of 'nullable' in the title. Second, from my understanding the issue is not specific to fkeys. It's that any nonnullable property is initialized to a nonnull value. But, as you say, this leads to problems. I agree that the current behavior of breeze is wrong. I'd say it is a design bug/error. It is dangerous since it leads to bad data being saved. It's better to fail save (since a non-nullable property is null) than to accidentally save a value that is valid (passes validation) but is arbitrary WRT the application.
-
150 votes
An error occurred while saving the comment @Anonymous The workaround that I know of is to define a special entry point in the web service (server controller) and execute a query in a more direct way.
-
14 votes
-
14 votes
-
15 votes
An error occurred while saving the comment I think the answer is to load the image data into the entity property and then save the entity. But, we have already run into the problem of performance for large images, files, blobs. My question is: does breeze have special support for large data upload ... and download ... that does not kill performance? We need a way to transfer the data of the blob separately from the rest of the entity data.
-
32 votes
An error occurred while saving the comment We need to support reading partial objects that contain a large property (database column) -- an image or file or some other kind of blob. At first, we want to read all of the object except for the large properties. Then, read the large columns later -- on demand. It would be nice if breeze cached the partial object such that the loaded properties could be edited and saved regardless of whether the blob was ever read. IOW, don't null out the blob field if we never actually load it. Further, allow saving the object without the on-demand field if only the non-on-demand fields have changed.
A note about implementing this change: It seems unwise to simply change the behavior of breeze as described here since that would change the behavior rather drastically. I suppose a good solution is to provide a single option to use null for all properties (even if it's nonnullable).