Re: ZODB with Lazy evaluation / Caching / Data Flow programming

"Wong, Byron" <[email protected]> Fri, 27 Apr 2018 14:43:36 +0800
Newsgroups gmane.comp.web.zope.zodb
Message-ID <CAGqXE6LEFkrjXq9uWN35q0cspEXcMzj93WBqiGxM3_HMZACtTw@mail.gmail.com>
Jim, Chris:

Thanks very much for your quick response. @Chris - thanks also to your
contribution to the ZODB community. I was listening to your YouTube talk
and the ZODB Demo app. It has helped me to learn to use ZODB better.

I am not building any top-secret project; Rather, Rather, I am trying to
use ZODB in a lot of places in my new job.

My experience perhaps it's a bit unique -- most people learn to just use
relational DB and get the job done. On the other hand, I actually have been
using Object Database in modelling and solving problem in my previous
company for ~8 years .... (not having to deal with the Object Relation
Impedance is awesome). However as I left the place, I have found myself
been trying to fight the productivity and efficiency I used to have (that's
before I bump into ZODB)

Now of course there are difference in how ZODB works and how the previous
in-house Object DB works.... and so I have been trying to find tools in the
Open Source community to replicate similar infrastructure. ZODB has solved
the object persistence problem, and the major missing piece now it's really
the whole Computational in-memory dependency graph caching/in-validation,
hence prompting me to ask the question here.

For my actual use case, I am building a Flask-based webApp which would have
controllers logic and models using ZODB. It's expected to run on multiple
computers. I am planning to use ZODB with RelStore backed by PostgresQL
(managed by Google Cloud SQL). Objects will be stored in the database, and
simple calculation will be Web service level. I will also be using Airflow
(the scheduler infrastructure written in Python) to schedule periodic
jobs.... that will query the database, pull objects, crunch some heavy
numbers, and write results back to Database.

With regards to the consistency across computers issues -- yes in my case,
it's fine that the read-only client are using a slightly stale data. In
fact, that was the model in my previous company... from time to time, they
will have to "refresh" the in-memory cache and ensure the state is
consistent with that's in the database. I saw the YouTube demo on 2 Tier
Kanban by Jim ... (this link
https://www.youtube.com/watch?v=6v1sIw5j4ss&t=11s)  and see how new feature
can automatically pop up after object being persisted in DB... that's seems
pretty awesome, but my guess is without some proper listener logic, it's
hard to achieve?

There are other projects that solved the cached dependency problems (like
the PythonFlow and MDF). However they are usually focusing on the
computational part -- and usually they don't design around the Object
Oriented notion... (they are usually functional in nature). As a result, I
often run into another kind of "impedance" problem -- in that when I am
modelling business logic and behavior... Object paradigm and ZODB are
perfect...... yet if I want to use the dependency tracking in-memory, I
have transform the object data into some functional representation.

In any event, glad to actually start posting my first post here in this
community. I also are experimenting the Newt.db thing.... seems a great
balance between the convenience in modelling and powerfulness of search.

Cheers,
Byron



On Fri, Apr 27, 2018 at 1:32 PM, Christopher Lozinski <
[email protected]> wrote:

> Thank you Jim for the excellent answer. The ability to
> update remote user interfaces sounds very interesting indeed.
>
>
> Baron, welcome to the ZODB community.  I am curious what you re building?
> What is the context for this question?  Or is it a top-secret startup?
>
> In particular what are your transactional requirements?  Is this
> application running on multiple computers?   Do you want to store the
> objects in the database, but have the calculations only be in RAM?  What
> about consistency across computers?
>
> Jim, please correct me if I am wrong, but here is how I believe that the
> ZODB works.  If both ZEO clients are reading a value, no problem.  If both
> are writing a value, one is first, its write completes, the other computer
> gets an error.  But if one is reading, while the other is writing, but
> before the cache is invalidated, the read goes through.  Even though the
> data is a bit out of date, it is not a problem in most cases.  Jim, is that
> a correct understanding?
>
> If that is the case, Baron do you need to make sure that no other server
> has recently updated a value?  How do the distributed dependency
> relationship graphs handle this problem?
>
> Warm Regards
> Chris
>
>
>
>

-- 
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.