I’m pretty sure you still have to call localObjects(), even if it’s a child context.
In any case, a hash map doesn’t really work for me, since I have a significant graph of objects, and relationships could fire at different levels. Thanks for your thoughts! > On Mar 29, 2018, at 6:07 PM, Mike Kienenberger <[email protected]> wrote: > > Like I said, I haven't used nested contexts, but I'm assuming that > data in the parent context is available to the child contexts, but > data in sibling contexts is not available to the child context. > > As for not nesting contexts too deep, I'm guessing that's a > performance issue rather than a technical limitation. This process > doesn't sound like it's an interactive time-sensitive operation, and > you've already said that memory isn't an issue (and data contexts are > not memory intensive in any case). > > Years ago, before Cayenne had child contexts, I handled situations > like yours by using a single context and a hashmap. > As I created new objects, I stored them in the hash map by the line > identifier, then pulled them back out later when I had a line that > referred to a previous line. > > > On Thu, Mar 29, 2018 at 5:50 PM, Ken Anderson > <[email protected]> wrote: >> Mike, >> >> The docs say to not go too deep with nested contexts, so I don't think >> that's a viable solution. I'm also not clear what benefit you think this >> would have over the 2 level plan. >> >> Ken >> >> On 3/29/18, 5:39 PM, "Mike Kienenberger" <[email protected]> wrote: >> >> Instead of having each line as a child context under a parent context, >> >> parent >> - child1 (line 1) >> - child2 (line 2) >> - child3 (line 3) >> >> could you have each line processed as a child context of the previous >> line? >> >> - child1 (line 1) >> -- child2 (line 2) >> --- child3 (line 3) >> ---- child4 (line 4) >> >> If you want to "undo" the current line, >> child4.rollbackChangesLocally(); and start on the next line. >> >> Note that I have not done anything with child contexts, but this would >> be how I'd try to solve it. >> >> >> On Wed, Mar 28, 2018 at 9:29 PM, Ken Anderson <[email protected]> wrote: >>> Hugi, >>> >>> That’s correct - it’s not like we’re just importing a bunch of records. >>> Each row in the file could affect the same set of objects. >>> >>> So, we did the child context, but obviously if we created an object in a >>> prior child and then saved it to the parent, we won’t be able to easily >>> find it in the next child context. If you get a localObject in your new >>> child context, it is “hollow”, so not connected to all the other objects >>> floating around in the parent. We also can’t fire relationships, because >>> those relationships will go to the database instead of the parent context. >>> >>> Ken >>> >>>> On Mar 28, 2018, at 7:11 PM, Hugi Thordarson <[email protected]> wrote: >>>> >>>>> That's exactly what we want to do - save once at the end. However, we >>>>> have 2 problems: >>>>> >>>>> 1. How do we find the objects that we already created but haven't saved >>>>> yet >>>> >>>> You can go through yur ObjectContext's newObjects() and filter that to >>>> your liking—pretty much the same as you'd do with EOF. >>>> >>>>> 2. How do we roll back each line if there's an error? Not a DB error, >>>>> but the logic gets so far, and then determines that there's no way to >>>>> continue so we must skip this line. >>>> >>>> As you tried yourself, I'd use a child context and commit to the parent >>>> once you're sure everything is in place. Can you explain further what was >>>> problematic with that (that you need to "access the same objects multiple >>>> times")? Do you mean that each row of the file is in some way looking at >>>> data from other rows? >>>> >>>> Cheers, >>>> - hugi >>>> >>>> >>>>> >>>>> Ken >>>>> >>>>> On 3/28/18, 6:07 PM, "John Huss" <[email protected]> wrote: >>>>> >>>>> Well, you could just save once at the end. Why do you need to save >>>>> multiple times during the processing? Validation exceptions and >>>>> Optimistic >>>>> Locking errors could be handled in the save with some custom logic and a >>>>> retry. >>>>> >>>>> Or if this isn't a super long process you can use a database transaction >>>>> to >>>>> allow saving multiple times without actually having that data be visible >>>>> outside of the transaction. >>>>> >>>>> >>>>> On Wed, Mar 28, 2018 at 6:56 AM Ken Anderson >>>>> <[email protected]> >>>>> wrote: >>>>> >>>>>> All, >>>>>> >>>>>> We have a process that reads in a file and, for each line, creates or >>>>>> edits objects in the object graph. We only want to commit to the >>>>>> database >>>>>> once at the end. >>>>>> >>>>>> We have a finite set of lines, so memory is not an issue. We need to >>>>>> save >>>>>> only once because saving will actually fire triggers that will start >>>>>> doing >>>>>> other things to the database, which will then lead to optimistic lock >>>>>> exceptions for us if we have data that overlaps (which we do). >>>>>> >>>>>> Please don’t suggest we change how the trigger pattern works – it’s a big >>>>>> system and we don’t have control over it. >>>>>> >>>>>> So, what we’ve toyed with is using a parent/child context arrangement, >>>>>> where each line is processed in a child, and assuming everything goes OK, >>>>>> we commit only to the parent. This works well as long as we don’t need >>>>>> to >>>>>> access the same objects multiple times, but unfortunately, we do. We can >>>>>> reach into the parent context’s unsaved objects, but those objects do not >>>>>> have any relationships since they were built in the child context. This >>>>>> makes things painful. >>>>>> >>>>>> In EOF, I might consider using a single context and undo, but it doesn’t >>>>>> seem like Cayenne has this kind of functionality. >>>>>> >>>>>> Thoughts? Suggestions? In EOF, I had once written a layer that >>>>>> intercepted all queries and tried to find the correct object in unsaved >>>>>> objects, but I don’t have nearly enough experience with Cayenne to do >>>>>> that. >>>>>> >>>>>> Thanks! >>>>>> Ken >>>>>> >>>>>> Confidentiality Notice: This e-mail and accompanying documents contain >>>>>> confidential information intended for a specific individual and purpose. >>>>>> This e-mailed information is private and protected by law. If you are not >>>>>> the intended recipient, you are hereby notified that any disclosure, >>>>>> copying, or distribution, or the taking of any action based on the >>>>>> contents >>>>>> of this information, is strictly prohibited. >>>>>> >>>>> >>>>> >>>>> Confidentiality Notice: This e-mail and accompanying documents contain >>>>> confidential information intended for a specific individual and purpose. >>>>> This e-mailed information is private and protected by law. If you are not >>>>> the intended recipient, you are hereby notified that any disclosure, >>>>> copying, or distribution, or the taking of any action based on the >>>>> contents of this information, is strictly prohibited. >>>> >>> >> >> >> Confidentiality Notice: This e-mail and accompanying documents contain >> confidential information intended for a specific individual and purpose. >> This e-mailed information is private and protected by law. If you are not >> the intended recipient, you are hereby notified that any disclosure, >> copying, or distribution, or the taking of any action based on the contents >> of this information, is strictly prohibited.
