Hunting Down Save Result Bug - breeze
I was looking for help trying to hunt down a bug with hasChanges still true after returning from a successful saveChanges. I am saving an entity and nested entity together and when it returns my saveResult is showing as an array with the first object showing the parent entity and the second object is a $ref. However one of my entityGroups is saying it still has changes so it acts like it needs to save again.
One interesting thing is that I saved a different set with a different nested entity and it returned with the nested entity as the first object in the saveResult array and my parent entity was the $ref. I did my best to make sure that both nested entity models looked the same. If anyone has any ideas or suggestions I will gladly give them a try and hopefully solve this issue.
{
"$id":"1",
"$type":"Breeze.ContextProvider.SaveResult, Breeze.ContextProvider",
"Entities":[
{
"$id":"2",
"$type":"CoreDBCodeFirst.Person, CoreDBCodeFirst",
"LastName":"Washington",
"FirstName":"George",
"MiddleName":null,
"SocialSecurity":null,
"DateOfBirth":"1974-12-10T06:00:00.000Z",
"Gender":"M",
"Language":"en-US",
"IdNumber":null,
"Eligibility":true,
"Active":true,
"PersonAddresses":[
{
"$id":"3",
"$type":"CoreDBCodeFirst.PersonAddress, CoreDBCodeFirst",
"Address1":"13000 S Dakota 244",
"Address2":null,
"Zip":"57751",
"City":"Keystone",
"State":"SD",
"IsPrimary":false,
"Active":true,
"PersonId":20118,
"Person":{
"$ref":"2"
},
"id":20108
}
],
"FullName":"Washington, George",
"Email":null,
"id":20118
},
{
"$ref":"3"
}
],
"KeyMappings":[
{
"$id":"4",
"$type":"Breeze.ContextProvider.KeyMapping, Breeze.ContextProvider",
"EntityTypeName":"CoreDBCodeFirst.Person",
"TempValue":-1,
"RealValue":20118
},
{
"$id":"5",
"$type":"Breeze.ContextProvider.KeyMapping, Breeze.ContextProvider",
"EntityTypeName":"CoreDBCodeFirst.PersonAddress",
"TempValue":-2,
"RealValue":20108
}
],
"Errors":null
}
Anytime you see a return value of a function in place of an entity, it's a good bet that there is something wrong with your metadata; usually having to do with the definition of one of your navigation properties. Can you post the metadata for Person and PersonAddresses?
Need more details.
What is the server tech?
What was your saveChanges call? Did you specify entities to save or ask to save the entire cache?
In a debugging session, capture the list of entities you're saving (manager.getChanges()) and compare them to the saveResult.entities in the response; are any entities missing?
Is anything remarkable about the unsaved entities after save?
Related
How to refresh previously bound entity every time user visits the page
I just ran into a problem where I am not sure how to solve. Background: I've got an App with two views: 1st one to input a number, 2nd one to see the details. After the view switched to the detail view, I would call the bindElement() to get my data from the backend. _onRoutePatternMatched: function(oEvent) { // ... this.getView().bindElement({ path: "/EntitySet('" + id+ "')" }); }, Problem is that the ID is quite often the same, hence, the method will call the backend only if the ID is different from the last call. So I tried to solve the problem by using the following: this.getView().getModel().read("/EntitySet('" + id+ "')",{ success: function(oData, response) { that.getView().setModel(oData, ""); } }); By this, the data is always up to date. But now the binding is a bit different. Binding with bindElement(): { "id": "1234", "propety1": "abc", // ... } Binding with setModel() and id = 1234: { "EntitySet('1234')": { "id": "1234", "propety1": "abc", // ... } } For the first way, my binding looked like this: <ObjectHeader title="{id}"> Now, it would have to look like this: <ObjectHeader title="{/EntitySet('1234')/id}"> And here I have a problem, because the value of id (in this case 1234) will always be different and so the binding won't work. I can't bind directly to the ObjectHeader, because I will need some properties from the model later. That is the reason I am binding to the view so that all that remain available. My idea was to edit the binding inside the success method of the read method. I would like to delete the surrounding element. Do you have an idea, how to do this? Or even a simpler/better idea to solve my pity? Edit: I forgot to mention the refresh method. This would be possible, but where do I have to put it? I don't want to call the backend twice.
Simply call the API myODataModel.invalidateEntry(<key>) before binding the context in order to retrieve the latest data. // after $metadata loaded.. const model = this.getOwnerComponent().getModel("odata"); const key = model.createKey(/*...*/) //See https://stackoverflow.com/a/47016070/5846045 model.invalidateEntry(key); // <-- before binding this.getView().bindElement({ path: "odata>/" + key, // ... }); From https://embed.plnkr.co/b0bXJK?show=controller/Detail.controller.js,preview invalidateEntrydoc Invalidate a single entry in the model data. Mark the selected entry in the model cache as invalid. Next time a context binding or list binding is done, the entry will be detected as invalid and will be refreshed from the server.
"EntityNotFoundException: Unable to load RELATIONSHIP with id" when saving RelationshipEntity (with huge generated cypher query)
I am using spring-data-neo4j 4.2.0.M1 and neo4j-ogm 2.0.4 with neo4j 3.1.0-M04. The application is generally working, except for one case where I try to save a collection of modified RelationshipEntities. The code is sth. like this: List<Relationship> updatedRelationships = new ArrayList<>(); for(Relationship relationship : modifiedRelationships) { relationship = relationshipRepository.load(relationship); relationship.setValue("value"); updatedRelationships.add(relationship); } relationshipRepository.save(relationships); The RelationshipEntity is annotated with #RelationshipEntity and has a few properties in addition to the #StartNode and #EndNode. Only the property mentioned above is changed though. The RelationshipEntity is loaded inside the loop because I previously noticed lost information (namely value of other properties) when executing this. Note that the above mentioned code is executes for many RelationshipEntities in succession. Each relationship (probably) occurs only once, but start and end nodes probably occur several times. To my knowledge, no relationship is deleted though. The exception I get is: Caused by: org.neo4j.kernel.api.exceptions.EntityNotFoundException: Unable to load RELATIONSHIP with id 20683203. at org.neo4j.kernel.impl.api.store.DiskLayer.relationshipVisit(DiskLayer.java:432) at org.neo4j.kernel.impl.api.store.CacheLayer.relationshipVisit(CacheLayer.java:326) at org.neo4j.kernel.impl.api.StateHandlingStatementOperations.relationshipVisit(StateHandlingStatementOperations.java:1409) at org.neo4j.kernel.impl.api.ConstraintEnforcingEntityOperations.relationshipVisit(ConstraintEnforcingEntityOperations.java:416) at org.neo4j.kernel.impl.api.OperationsFacade.relationshipVisit(OperationsFacade.java:493) at org.neo4j.kernel.impl.factory.GraphDatabaseFacade.getRelationshipById(GraphDatabaseFacade.java:300) ... 104 common frames omitted The query that is executed before (which is probably the "save" query) is huge and exceed the character limit here (sth. like 200k characters). Apparently the query touches where more relationships than necessary (from business logic point-of-view) since only about 30 entities are actually saved. I would assume that the resulting query (or queries if updates are done per entity) are rather brief. 2016-08-28 20:16:33,007 I [pool-4-thread-1 ] (EmbeddedRequest.java:155) Request: START r=rel({relIds}) FOREACH (row in filter(row in {rows} where row.relId = id(r)) | SET r += row.props) RETURN ID(r) as ref, ID(r) as id, {type} as type with params {relIds=[13744338, 19099951, 12570789, 12570785, 13744377, 13648126, 12570765, 20627727, 13744356, 20627724, 12570760, 19263773, 19257628, 20113678, 19099932, 19259756, 18796874, 13783174, 19097972, 19083644, 19099970, 19097921, 19077446, 19263810, 13744312, 20568405, 20904270, 19097937, 12570827, 20627779, 20648258, 12570816, 20683195, 19259812, 20683194, 20683193, 20683192, 19083690, 20683186, 20683191, 19259819, 18819471, 20683178, 20683177, 12570669, 20683176, 19276210, 19933607, 20683171, 18844038, 19100089, 20683174, 20683173, 20683163, 20683162, 20683161, 13744242, 19257729, 12570649, 20683165, 20683164, 19087754, 21703141, 12570641, 8341711, 19259796, 8704051, 19915155, 19261851, 13783062, 13783063, 19091955, 18182597, 19276276, 19276275, 20623852, 20607468, 20623853, 19100155, 19233277, 13783048, 19261946, 12570719, 21789101, 12570718, 19075526, 19259842, 19257807, 12570707, 13715516, 19098061, 19261908, 20683208, 20683215, 19100118, 20683212, 20683203, 19276254, 20683201, 20683207, 19091934, 20683206, 19261915, 19097639, 19101736, 19101749, 18821129, 19097659, 19124284, 13662709, 13744628, 19052549, 19089427, 13744612, 19265563, 19251300, 19089509, 19251298, 20631665, 19251305, 19265642, 13744513, 19261558, 19261511, 19265606, 19081291, 18903113, 18903114, 19251273, 8341775, 12597685, 13744548, 19081308, 18725021, 18725020, 19273892, 19099808, 19089572, 19097772, 13744449, 13683011, 18178177, 19273905, 19093694, 18178231, 19124358, 20633756, 13744502, 19081356, 18651311, 19093661, 20562171, 19263725, 20625639, 19099901, 20631774, 20676819, 18651383, 20676822, 20676821, 20676820, 19097811, 19099862, 13744428, 20631751, 18178280, 18668312, 19100453, 19088171, 20708148, 19143487, 19088184, 19094334, 18668349, 13744883, 19145485, 20607750, 19094301, 19086108, 13744792, 20611958, 19143528, 13662849, 13744829, 12571346, 20611918, 20611919, 18811753, 19100506, 13744813, 19084195, 13662806, 20708275, 19098546, 20612001, 13744752, 20708253, 12595823, 20611976, 19147673, 19258343, 19274725, 19084262, 19082212, 19096548, 20591606, 19086317, 13662720, 8348332, 19274738, 8348329, 19096571, 21703569, 19440630, 13744654, 21824427, 13744701, 19258320, 20612032, 19086296, 19080158, 19282466, 19145249, 19261996, 20607539, 12596170, 19282472, 18776588, 19100208, 12596183, 18182658, 19233341, 19278395, 19096126, 19098115, 20640284, 18844217, 19255810, 19259919, 19257864, 20623892, 19091980, 19933697, 19282450, 19100180, 19261981, 12596219, 12596113, 19255924, 20707949, 12596118, 19098228, 18704970, 12596122, 19278458, 19096190, 19278456, 19253826, 19278412, 13745087, 19100241, 13745066, 18704995, 19278500, 13744981, 5954519, 19094199, 19143356, 13744970, 12598116, 18840242, 13745006, 18676445, 18008789, 19096298, 18676426, 20607724, 13744906, 13755199, 19094227, 12596419, 19098918, 19256621, 19090736, 21075287, 19100929, 21851496, 20876568, 13681912, 12596463, 12596465, 19090704, 10951825, 12596471, 13681897, 13753581, 19094814, 12596352, 21703948, 21695756, 18699605, 19256693, 18818378, 12596376, 19090755, 19256647, 13681844, 19082583, 18836839, 18699621, 12596409, 20618681, 21544395, 19916202, 12596299, 12596310, 19436940, 19099014, 19094918, 19916170, 13681782, 12596335, 20680073, 13681762, 13681763, 19099028, 19094938, 21081473, 13681682, 20680177, 12596242, 19099126, 19500540, 21081496, 10492993, 19099087, 21081517, 19099094, 21704112, 19098665, 18680849, 12596685, 12596689, 19274804, 20648995, 19137597, 21048411, 19088387, 19262470, 20657183, 19086357, 19258397, 18680869, 12596731, 19088413, 19272807, 19274848, 19272811, 12596622, 18811984, 15797667, 19096694, 19082357, 19262579, 19274875, 19137604, 12596642, 19274830, 19098696, 13682107, 12596651, 19096655, 20632650, 19088474, 19274845, 19262555, 19100834, 13682007, 19098794, 19100851, 12596565, 20556972, 19254450, 20597926, 12598622, 20597925, 20649114, 19100800, 13682036, 19100806, 12596582, 18703539, 20638856, 20598010, 18703582, 19094763, 19100905, 19096808, 20634857, 20597991, 5877179, 5877178, 20597977, 5877181, 19098822, 12596527, 12596532, 19199781, 19265313, 19261228, 20625200, 19257134, 20625201, 18714376, 19085108, 19253054, 19253048, 19265339, 20637459, 20637456, 19085074, 21081974, 8316482, 20598534, 18714402, 19107685, 19253090, 20615029, 19097462, 19263346, 20621152, 19263352, 19259207, 13729470, 19085140, 20688830, 19251116, 19259304, 13678173, 20615087, 12596830, 19097474, 21082087, 12596840, 19263368, 19251093, 8701488, 19267475, 8349384, 12572165, 8349360, 12596751, 19077119, 12596765, 20625380, 19077057, 19089350, 21825447, 21702567, 13682208, 12596785, 8316559, 18178020, 19253207, 20688847, 12596788, 19267536, 20688838, 12570558, 19232295, 12570550, 13783001, 20643352, 20694547, 19095051, 20643338, 19232272, 12570505, 20641280, 20694529, 20641284, 19099164, 20821624, 20821626, 20631165, 20821619, 12570606, 19439229, 12570601, 18820674, 19232327, 12570588, 20694621, 20641362, 20119134, 20631115, 20680264, 20618831, 19093080, 18824862, 19256994, 7325670, 20821668, 19257017, 13782863, 16494427, 20620952, 19256967, 20637331, 18030271, 8267731, 19256977, 20670095, 19099360, 20637433, 19261170, 19265276, 20907749, 18822910, 20621021, 19099339, 19252938, 19936961, 19099345, 19109599, 19257048], rows=[omitted] I've tried to load the relationship with that id directly, but none exists. The same code executes fine for other RelationshipEntities but repeatedly fails for either this or one of a handful other ones. Any ideas as to what could cause this or how this can be better debugged?
I think I somehow solved this with the following steps: Replaced saving the RelationshipEntity with saving the modified NodeEntity Making such modifying operations sequential (previously this could happen in parallel) Encapsulate the modifying operation in a transaction Fixed a bug where in the same transaction the same entity was saved twice (without changing again in the meantime) Fetching the entity again at the beginning of the transaction in order to have the latest state available Since I was prettty much in the dark about this topic until it finally worked, I am not sure if all of the steps actually helped solving this. It may actually have been only a subset. What I can see though now is, that the huge update queries are now smaller (albeit still quite big) but actually seem to contain "real" updates instead of mostly "null" properties. I assume that previously it didn't really contain an update and was instead overriding properties with "null". The fact that this is now working is probably related to the fact, that the entity is now updated before beginning to modify it and that no other modifying operation can run in parallel.
I had the same problem. For me it was simply the neo4j-ogm-embedded-driver version I had to include in my pom. The one I defined overwrote the one defined in spring-data-neo4j.
If you only save the relationshipEntity,you could only using next snippet: List<Relationship> updatedRelationships = new ArrayList<>(); for(Relationship relationship : modifiedRelationships) { relationship = relationshipRepository.load(relationship); relationship.setValue("value"); updatedRelationships.add(relationship); } relationshipRepository.save(updatedRelationships,0); it would save the related properties on relationshipEntity and meanwhile ignore any related entities.
EmberJS, Loading first object on page load
Hopefully, a simple question and must have a simple answer but i have wasted almost 3hrs in getting out of this issue. I have a user model. I want to load the first user from DB and show it on first page load. What i am trying to use is: in my ArrayController, init: function(){ var user = App.User.find(1) console.log(user); this.set('defualtUser',user.get('name')) } But i cant get the name of user. Here is the output of user in console, which indicates that data is being loaded but i can't just get it to use. Class __ember1367188634172: "ember270" __ember1367188634172_meta: Meta _changesToSync: Object _data: Object attributes: Object ***name: "Cafe Alpino"*** __proto__: Object belongsTo: Object hasMany: Object id: null __proto__: Object See the name: "Cafe Alpino", i just want to display this name. Any help??? BTW, i am a newbie with EmberJS
I think the problem here is asynchronousy. This line: var user = App.User.find(1) will result in a user record that is not loaded yet; its properties aren't set until the AJAX call returns in the background. Therefore, user.get('name') will be empty. There are probably a few ways to solve this. I haven't used Ember Data too much (since it's not very solid at the moment), but according to the docmentation, there should be a didLoad event that you can use: init: function() { var user = App.User.find(1); var _this = this; user.on('didLoad', function() { _this.set('defaultUser', user.get('name')); }); } Give it a try! Let me know if it doesn't work out.
Storing graph-like structure in Couch DB or do include_docs yourself
I am trying to store network layout in Couch DB, but my solution provides rather randomized graph. I store a nodes with a document: {_id , nodeName, group} and storing links in traditional: {_id, source_id, target_id, value} Following multiple tutorials on handling joins and multiple relationship in Couch DB I created view: function(doc) { if(doc.type == 'connection') { if (doc.source_id) emit("source", {'_id': doc.source_id}); if(doc.target_id) emit("target", {'_id': doc.target_id}); } } which should have emitted sequence of source and target id, then I pass it to the list function with include_docs=true, assumes that source and target come in pairs stitches everything back in a structure like this: { "nodes":[ {"nodeName":"Name 1","group":"1"}, {"nodeName":"Name 2","group":"1"}, ], "links": [ {"source":7,"target":0,"value":1}, {"source":7,"target":5,"value":1} ] } Although my list produce a proper JSON, view map returns number of rows of source docs and then target docs. So far I don't have any ideas how to make this thing working properly - I am happy to fetch additional values from document _id in the list, but so far I havn't find any good examples. Alternative ways of achieving the same goal are welcome. _id values are standard for CouchDB so far. Update: while writing a question I came up with different view which sorted my immediate problem, but I still would like to see other options. updated map: function(doc) { if(doc.type == 'connection') { if (doc.source_id) emit([doc._id,0,"source"], {'_id': doc.source_id}); if(doc.target_id) emit([doc._id,1,"target"], {'_id': doc.target_id}); } }
Your updated map function makes more sense. However, you don't need 0 and 1 in your key since you have already "source"and "target".
db4o issue with graph of objects
I am a new to db4o. I have a big problem with persistance of a graph of objects. I am trying to migrate from old persistance component to new, using db4o. Before I peristed all objects its graph looked like below (Take a look at Zrodlo.Metadane.abstrakt string field with focused value) [its view from eclipse debuger] with a code: ObjectContainer db=Db4o.openFile(DB_FILE); try { db.store(encja); db.commit(); } finally{ db.close(); } After that, I tried to read it with a code: ObjectContainer db=Db4o.openFile((DB_FILE)); try{ Query q = db.query(); q.constrain(EncjaDanych.class); ObjectSet<Object> objectSet = q.execute(); logger.debug("objectSet.size" + objectSet.size()); EncjaDanych encja = (EncjaDanych) objectSet.get(0); logger.debug("ENCJA" + encja.toString()); return encja; }finally{ db.close(); } and I got it (picture below) - string field "abstrakt" is null now !!! I take a look at it using ObjectManager (picture below) and abstrakt field has not-null value there!!! The same value, that on the 1st picture. Please help me :) It is my second day with db4o. Thanks in advance! I am attaching some code with structure of persisted class: public class EncjaDanych{ Map mapaIdRepo = new HashMap(); public Map mapaNazwaRepo = new HashMap(); } !!!!!!!!UPDATED: When I tried to read only Metadane object (there was only one such a object), it is all right - it's string field abstrakt could be read correctly. try{ Query q = db.query(); q.constrain(Metadane.class); ObjectSet<Object> objectSet = q.execute(); logger.error("objectSet.size" + objectSet.size()); Metadane meta = (Metadane) objectSet.get(0); logger.debu("Metadane" + meta.toString()); return meta; }finally{ db.close(); }
This is a common db4o FAQ, an issue with what db4o calls "activation". db4o won't instantiate the entire graph you stored when you load an object from an ObjectContainer. By default, objects are instantiated to depth 5. You can change the default configuration to a higher value, but that is not recommended since it will slow down object loading in principle because the depth will be used everywhere you load an object with a query. Two approaches are possible to solve your issue: (1) You can activate an object to a desired depth by hand when you need a specific depth. db.activate(encja, 10) // 10 is arbitrary (2) You can work with Transparent Activation. There are multiple chapters on how to use Transparent Activation (TA) in the db4o tutorial and in the reference documentation.
You're not setting a filter in your query so you're reading the first object. Are you sure you didn't have a previous object in the database?