How about creating a local in memory database. Do all your file reads
and object creation to the in memory database. You could do the save
changes as many times as you like locally in memory. Then when you're
done, figure out what's new, what's been updated and create a new
connection to your remote db, and do the work once there in one transaction.
Could get a bit messy when it comes to updating objects that exist
already, you'd have to fetch them from the remote db and instantiate
them in the local db, but this way you have all your changes in a place
where the "side-effect" of doing the commits won't trigger the larger
process.
having a modified date, and a create date on your objects would go a
long way to making sure you knew what objects had changed. You might
still have to figure out which properties need to be updated. The
difficulty of this solution directly ties to the number of attributes in
your objects and the number of objects you're modifying.
What's the order of magnitude of the data are you parsing?
Tony Giaccone
On 3/28/18 7:56 AM, Ken Anderson 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.
