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.