Re: Applause for ZODB! And a question: How do you get pending change info from a transaction object?
Jim Fulton <[email protected]> Sat, 28 Apr 2018 13:50:16 -0600
| Newsgroups | gmane.comp.web.zope.zodb |
|---|---|
| Message-ID | <CAPDm-FjCxn5HcZYhBGFyGLEPOH4tCypCWKy5q5YoGkALCatMQQ@mail.gmail.com> |
On Fri, Apr 27, 2018 at 5:44 PM, David Pesta <[email protected]> wrote: > Hi Jim, > > I read much of what you wrote in these Google discussions and I want you > to know that I am mightily impressed with your philosophies and industry > perspectives and I am sympathetic about your frustrations. Rest assured, as > CPU technology goes beyond silicon (beyond 4ghz per thread) and as RAM > continues to explode, the masses for MANY business purposes will adopt > things like ZODB for the same reasons that they went beyond assembly to C > and beyond C to Java and better: Python. The day is approaching when the > time-to-market advantage will put players who choose things like ZODB way > above their competition. Don't let forum activity fool you. You have more > people eyeing your achievements than you think. As for me, I have been > gifted with the great blessing that ZODB is a perfect fit for my new > project. > > Now, here is what I am trying to accomplish. Perhaps you know of entirely > better ways to do what I am doing. Feel free to share! I am working toward > the development of a websocket connection in a Tornado app that is keeping > track of multiple client persistent connections. I have chosen ZODB to be > my source of truth for all data of the application. As soon as the ZODB > transaction commits, I want all clients to get sent a message to inform > them of changes to all of the specific objects that they are listening to > changes for. > > Keeping track of user client sockets and telling each of them to maintain > a list of object ids to pay attention to isn't going to be a hard thing > from what I can tell. I just need a way to hear from ZODB what the object > ids are that have changed when a commit happens. I came across > Synchronizers and can see where beforeCompletion might somehow be useful to > acquire the object ids that are about to be changed and afterCompletion > could be used to fire off the event and pass the list of changed object ids > (and could acquire the new object states at that time to send to the > sockets asking for it). > > With the following: > transaction.manager.registerSynch(MySynch) > > The MySynch beforeCompletion method that I implement would tell MySynch > about objects being changed in some temporary class variable. Then, the > MySynch afterCompletion that I implement would ultimately have access to > sockets and send those sockets the changes they are interested in knowing > about. (Most importantly I think I need the object ids from transaction > because there should be a way to re-fetch the current values via just the > ids, right?) > > Now, the documentation shows that the beforeCompletion method is passed > the transaction object and only the transaction object. What I need to know > from the transaction object is what object ids are getting ready to be > changed. I probably don't need to know what all of the changes are yet, > because I might be able to fetch all that in the afterCompletion--though it > could still be helpful to also know what the changes are. In short, how do > I get ids for objects that are about to change from the transaction object? > > I haven't proven any of this out yet, so maybe my whole approach is flawed > or inefficient. Maybe you know of a much better approach, or even a more > awesome set of supporting technologies for all this. If so, don't hesitate > to share! :) > I wouldn't use transaction hooks for this because they only run on a single application server. (And likely other reasons.) What you want to do is get notified of database changes at a deeper level. If you're using RelStorage with a Postgres backend, you can use the Newt DB follow API, http://www.newtdb.org/en/latest/topics/following.html. See the response I just sent to Byron Wong. For ZEO, this used to be easier than it is now, because of some refactoring that happened in ZODB 5. If you're using ZEO, I can provide instructions for doing a hack and, a little later, add an API. Jim -- Jim Fulton http://jimfulton.info -- You received this message because you are subscribed to the Google Groups "zodb" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.