[ZODB] There is a market for the the ZODB.

[Christopher Lozinski]

People are hugely interested in learning about graph databases.

I thought that when I gave a talk on the ZODB, it was about pushing it as a commercial product.
How many users, what is its performance, how big can the database be?

That is all wrong. The reason that people come to a talk on the ZODB, is because
they are interested in learning about graph databases. So my new talk title is

“Introduction to graph databases using the ZODB as an example”

And then my focus is on communicating the concepts. And then the stuff about performance,
maturity, and number of users just comes at the end.

And because my focus is now on the concepts, people end up with a much better understanding
of the ZODB. There was the example of the person who asked a few days ago about changing
the class of an object. The reason he had that problem is because he did not quite have the right
concepts. "Read the code” is the advice we all get. But much more friendly would be: “Here is a nice video
about the concepts behind the ZODB. “

I will be giving this talk again at PyCon DE. The conference title is “ZODB the Graph Database for
Python Developers. " If anyone is interested in giving such a talk at their local meetup, here re the slides.
https://pythonlinks.info//presentations/zodbtalk.pdf <https://pythonlinks.info//presentations/zodbtalk.pdf>

It is also a good way to get a free admission to a local Python Conferences.

And of course if enough people like the talks, some will start using the ZODB.

Which would be good for all of us.

Warm Regards
Christopher Lozinski

https://PythonLinks.info
tel: [phone]
Skype: clozinski

[Andreas Jung]

I attended this talk that there was a huge amount of nonsense in this talk,
apart from the poor and chaotic presentation.

Trying to sell the ZODB a graph database...well, nice try.

Of course a hierarchical storage is some kind of graph.

But we are in 2018 and we have have graph databases like Neo4J or
multi-model database like ArangoDB which work perfectly as graph database.

A graph database requires higher level query functionality like calculating
the shortest path etc.

Check the API of ArangoDB for this purpose:

https://docs.arangodb.com/3.2/AQL/Graphs/Traversals.html

There is nothing comparable in ZODB. Even a standard catalog on top of the
ZODB does not make it a graph database.

The ZODB is a transactional, hierarchical grave for Python pickles. Point.

The ZODB served us well for two decades and it is still doing its job but
please stop promoting the ZODB for the wrong purpose.

In particular you gave the very same talk some years ago at the Plone
conference in Bucharest or so...you just added some slides with graph
database stuff but that
does not turn the ZODB out of the sudden into a graph database.

You also mentioned ZeroDB as decent solution. This project is unmaintained
or even dead since > 2 years.

My point: you constructed a pointless usecase for the ZODB in a pretty poor
way.

My recommendation for a graph database together with an document store is
ArangoDB.
This is meanwhile our primary choice when you need the power of a document
store combined with the defining arbitrary relations between documents
together with a powerful query API that allows to query both the documents
and the graph. But using a hierachical object store that mimics relations
in some way does not make it a graph database.

-aj

Post by Christopher Lozinski
People are hugely interested in learning about graph databases.
I thought that when I gave a talk on the ZODB, it was about pushing it as
a commercial product.
How many users, what is its performance, how big can the database be?
That is all wrong. The reason that people come to a talk on the ZODB, is because
they are interested in learning about graph databases. So my new talk title is
“Introduction to graph databases using the ZODB as an example”
And then my focus is on communicating the concepts. And then the stuff about performance,
maturity, and number of users just comes at the end.
And because my focus is now on the concepts, people end up with a much better understanding
of the ZODB. There was the example of the person who asked a few days ago about changing
the class of an object. The reason he had that problem is because he did
not quite have the right
concepts. "Read the code” is the advice we all get. But much more
friendly would be: “Here is a nice video
about the concepts behind the ZODB. “
I will be giving this talk again at PyCon DE. The conference title is
“ZODB the Graph Database for
Python Developers. " If anyone is interested in giving such a talk at
their local meetup, here re the slides.
https://pythonlinks.info//presentations/zodbtalk.pdf
It is also a good way to get a free admission to a local Python Conferences.
And of course if enough people like the talks, some will start using the ZODB.
Which would be good for all of us.
Warm Regards
Christopher Lozinski
https://PythonLinks.info
tel: [phone]
Skype: clozinski

...

[Christopher Lozinski]

Thank you for the comments. It is most difficult to get good constructive criticism. So I will go ahead and integrate your comments into the next version of my talk.

First let me address specific criticisms of the ZODB, and then we will talk about our different points of view. Forgive me if I first restate your criticisms more politely. And I will add a few other common criticisms.

1. The ZODB is a hierarchical database.

This is a common misconception. That is why in my talk I start off with the canonical Neo4J example, and show how it is implemented in the ZODB by Graphagus. So that people would understand that the ZODB does graphs as well as hierarchies. Throughout my talk I kept repeating that message, that the ZODB also does graphs.

Actually web site URL’s are hierarchical, so if one is building a website, the ZODB, traversal, and views on objects work great.

2. The ZODB stores data in Pickles.


Well in order to serialize data and store it on the hard drive, you have to use something. You recommended ArrangoDB.

From Wikipedia:
The database... internally ... uses ArangoDB's VelocyPack – a fast and compact binary format for serialization and storage.[7] <https://en.wikipedia.org/wiki/ArangoDB#cite_note-7>

So you think that Velocity Pack is a better choice than Python Pickles?
Indeed my talk was clearly labelled “
For Python Developers.“ In fact I am just in the
process of debugging a copy command. it uses Python Pickles. Easy for me to debug
entirely in Python. proving that the ZODB is great for Python developers. If I were to do that in
ArrangoDB, I would need access to a C development tool set.

Thank you for helping me to better understand this particular advantage of the ZODB
over ArangoDB

3. The ZODB does not serve JSON.

And while it is true that the ZODB does not natively include software for converting
an object to json, there are a number of Python libraries which do that. I serve a
number of json files over at PythonLinks.info <http://pythonlinks.info/> It is easy to serve data however you wish. Even better would be Apache Avro. There are Python libraries to help me do that. Does ArrangoDB serve Apache Avro files? I think not.

4. The ZODB is old.

Python also is old. Are you suggesting that we not use Python? I find that software matures. The most recent version of Python keep getting better.
The same is true of the ZODB. It is old, mature, well tested. Very stable and mature. Its api is not constantly changing.
I think of its age as an advantage.


5. The ZODB does not scale.

Just store your data in PostgreSQL and it will scale as well as any database.

6. There is no company behind it.

Well indeed the Zope Corporation went bankrupt a long time ago, but the open source ZODB continues to be upgraded and improved. What will happen if Arrango Corporation goes broke? Are you worried about that?

7. The ZODB does not support indices.

Well just write your own, or use NewtDB which integrates the ZODB into PostgreSQL and their high performance indices.


8. The ZODB does not have edge objects.

Well it does have edges, the references between objects. It does not have additional properties on those edges. But then I do not need that.
And if you need explicit edge objects, Graphagus added them in 500 lines of code. Actually at the time, the graphagus benchmarks were faster than the Neo4J benchmarks. In the meantime, I have no edge objects, and my code is simpler.

9. The ZODB does not have a query language.

There is a project to add GraphQL to Plone. Zope.interface should make that quite easy to do. Probably not that hard to add NetworkX or a python version of Gremlin to the ZODB. Actually as a Python developer, I am quite happy without a query language. Maybe my life is simpler with everything in Python. I use innovative Javascript query tools on the client. ArrangoDB would not help me there.



Did I miss any of the major ZODB criticisms? I will add these to the next version of my talk.


POINTS OF VIEWS

Now let us get onto the issues of point of view. I targeted this talk at developers using both Python and a relational database, considering using a graph database.

I think of myself as a Python developer. I want to make things as simple as possible. Using the ZODB as a database is so much easier than using a relational database. That is the focus of my talk.

You are part of a different community You are a seasoned Arrango Graph database user. You have certain expectations from a graph database. The ZODB does not meet your needs. I understand that.


I would say that there are two types of databases. Object Graph and Property Graph. The ZODB is an object graph database. I believe that ArrangoDB and Neo4J are property graph databases. And yes, the ZODB is not a property graph database. Nor does it include a query language. Does that mean that the ZODB is just a hierarchical database? Technically not correct. Nor are you the language police.

There were a number of other mischaracterizations of my statements. ZeroDB, although no longer maintained is a very interesting concept. I am sure that the software still works. That is the advantage of a mature database. I am sorry that people do not care more about privacy.

Nor did I create a use case for the ZODB as a replacement for Neo4J or ArangoDB. That was entirely in your mind. My point was that it is really easy for Python developers to use compared to a relational database.

I am grateful for your feedback. It is always good to be polite. Another important skill is to understand other people’s points of views. And finally it is important to support diversity. Sometimes ArrangoDB is a better choice, sometimes the ZODB is a better choice.

Chris

[Andreas Jung]

Again, the ZODB is not a graph database. You can store graphs with very
database type. You could store graph information on the filesystem and use
grep for searching on the data. That does not make a storage graph
database. We have build a bunch of project on top of graph databases and
none of them could be implemented in reasonable, scalable and maintainable
way with the ZODB. I appreciate your energy for promoting such an old
technology and the ZODB still has its use cases. But never ever for a
(large scale) graph database. As said: the ZODB does not provide any graph
related query capabilities which are standard and often needed in graph
databases. And the ZODB is not suitable for building arbitrary graph
related solutions in 2018. Storing data is one point of a database, the
capability to query and manipulate data (at large scale) is different
point. The average Python developers should know nowadays about database
options. So promoting the ZODB as graph database on the same level as Neo4J
and others is just absurd.

-aj

Post by Christopher Lozinski
Thank you for the comments. It is most difficult to get good constructive
criticism. So I will go ahead and integrate your comments into the next
version of my talk.
First let me address specific criticisms of the ZODB, and then we will
talk about our different points of view. Forgive me if I first restate
your criticisms more politely. And I will add a few other common
criticisms.
1. The ZODB is a hierarchical database.
This is a common misconception. That is why in my talk I start off
with the canonical Neo4J example, and show how it is implemented in the
ZODB by Graphagus. So that people would understand that the ZODB does
graphs as well as hierarchies. Throughout my talk I kept repeating that
message, that the ZODB also does graphs.
Actually web site URL’s are hierarchical, so if one is building a website,
the ZODB, traversal, and views on objects work great.
2. The ZODB stores data in Pickles.
Well in order to serialize data and store it on the hard drive, you have
to use something. You recommended ArrangoDB.
The database... internally ... uses ArangoDB's VelocyPack – a fast and
compact binary format for serialization and storage.[7]
<https://en.wikipedia.org/wiki/ArangoDB#cite_note-7>
So you think that Velocity Pack is a better choice than Python Pickles?
Indeed my talk was clearly labelled “
For Python Developers.“ In fact I
am just in the
process of debugging a copy command. it uses Python Pickles. Easy for me to debug
entirely in Python. proving that the ZODB is great for Python developers.
If I were to do that in
ArrangoDB, I would need access to a C development tool set.
Thank you for helping me to better understand this particular advantage of the ZODB
over ArangoDB
3. The ZODB does not serve JSON.
And while it is true that the ZODB does not natively include software for converting
an object to json, there are a number of Python libraries which do that. I serve a
number of json files over at PythonLinks.info <http://pythonlinks.info/>
It is easy to serve data however you wish. Even better would be Apache
Avro. There are Python libraries to help me do that. Does ArrangoDB serve
Apache Avro files? I think not.
4. The ZODB is old.
Python also is old. Are you suggesting that we not use Python? I find
that software matures. The most recent version of Python keep getting
better.
The same is true of the ZODB. It is old, mature, well tested. Very
stable and mature. Its api is not constantly changing.
I think of its age as an advantage.
5. The ZODB does not scale.
Just store your data in PostgreSQL and it will scale as well as any database.
6. There is no company behind it.
Well indeed the Zope Corporation went bankrupt a long time ago, but the
open source ZODB continues to be upgraded and improved. What will happen
if Arrango Corporation goes broke? Are you worried about that?
7. The ZODB does not support indices.
Well just write your own, or use NewtDB which integrates the ZODB into
PostgreSQL and their high performance indices.
8. The ZODB does not have edge objects.
Well it does have edges, the references between objects. It does not have
additional properties on those edges. But then I do not need that.
And if you need explicit edge objects, Graphagus added them in 500 lines
of code. Actually at the time, the graphagus benchmarks were faster than
the Neo4J benchmarks. In the meantime, I have no edge objects, and my
code is simpler.
9. The ZODB does not have a query language.
There is a project to add GraphQL to Plone. Zope.interface should make
that quite easy to do. Probably not that hard to add NetworkX or a python
version of Gremlin to the ZODB. Actually as a Python developer, I am quite
happy without a query language. Maybe my life is simpler with everything in
Python. I use innovative Javascript query tools on the client. ArrangoDB
would not help me there.
Did I miss any of the major ZODB criticisms? I will add these to the next
version of my talk.
POINTS OF VIEWS
Now let us get onto the issues of point of view. I targeted this talk at
developers using both Python and a relational database, considering using a
graph database.
I think of myself as a Python developer. I want to make things as simple
as possible. Using the ZODB as a database is so much easier than using a
relational database. That is the focus of my talk.
You are part of a different community You are a seasoned Arrango Graph
database user. You have certain expectations from a graph database. The
ZODB does not meet your needs. I understand that.
I would say that there are two types of databases. Object Graph and
Property Graph. The ZODB is an object graph database. I believe that
ArrangoDB and Neo4J are property graph databases. And yes, the ZODB is
not a property graph database. Nor does it include a query language.
Does that mean that the ZODB is just a hierarchical database? Technically
not correct. Nor are you the language police.
There were a number of other mischaracterizations of my statements.
ZeroDB, although no longer maintained is a very interesting concept. I
am sure that the software still works. That is the advantage of a mature
database. I am sorry that people do not care more about privacy.
Nor did I create a use case for the ZODB as a replacement for Neo4J or
ArangoDB. That was entirely in your mind. My point was that it is really
easy for Python developers to use compared to a relational database.
I am grateful for your feedback. It is always good to be polite. Another
important skill is to understand other people’s points of views. And
finally it is important to support diversity. Sometimes ArrangoDB is a
better choice, sometimes the ZODB is a better choice.
Chris

...

[Christopher Lozinski]

How about if we call the ZODB an object-graph database, to distinguish it from your definition of a graph database. Indeed a ZODB application is a graph of Python objects.

Would that work for you?
Chris

[Andreas Jung]

I don't care how you call it.
Call it Bob - as long as you don't mention "graph" again in the context of
the ZODB.

Post by Christopher Lozinski
How about if we call the ZODB an object-graph database, to distinguish it
from your definition of a graph database. Indeed a ZODB application is a
graph of Python objects.
Would that work for you?
Chris

[tk]

Post by Andreas Jung
I don't care how you call it.
Call it Bob - as long as you don't mention "graph" again in the context
of the ZODB.

lol. semantics do matters... ;-)

tk

Post by Andreas Jung
How about if we call the ZODB an object-graph database, to
distinguish it from your definition of a graph database.   Indeed a
ZODB application is a graph of Python objects.
Would that work for you?
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
For more options, visit https://groups.google.com/d/optout.

[Andreas Jung]

This discussion is hilarious.

Do we call Postgres a graph database just because you can store a graph
based on the relational model?

Do we call Postgres a document store just because you can store meanwhile
JSON documents?

Do we call Neo4J a relational database just because you could model
relations as a graph?

The ZODB is a transactional, hierarchically organized store for Python
pickles aka object store.

As stated a database consists in my definition of the storage layer and a
query layer.

The ZODB is clearly a storage-only implementation without a query engine
(besides the low-level traversal logic).
It clearly lacks any higher level query functionality as it was implemented
as part of the ZCatalog.

-aj

Post by tk

Post by Andreas Jung
I don't care how you call it.
Call it Bob - as long as you don't mention "graph" again in the context
of the ZODB.

lol. semantics do matters... ;-)
tk

Post by Andreas Jung
Am Sonntag, 28. Oktober 2018 17:06:30 UTC+1 schrieb Christopher
How about if we call the ZODB an object-graph database, to
distinguish it from your definition of a graph database. Indeed a
ZODB application is a graph of Python objects.
Would that work for you?
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
For more options, visit https://groups.google.com/d/optout.

--
Etienne Robillard
https://www.isotopesoftware.ca/

...

[Jim Fulton]

On Sun, Oct 28, 2018 at 10:39 AM Andreas Jung <***@gmail.com> wrote:
...

Post by Andreas Jung
The ZODB is a transactional, hierarchically organized store for Python
pickles aka object store.

That is incorrect. ZODB does in fact store an object graph. It isn't
limited, no does it depend on hierarchies in any way.

It shares with graph databases the property that graphs are very easy to
represent and use.

While it's possible to represent graphs in relational databases, it is
difficult and inefficient, compared to ZODB in my experience.

I prefer to describe ZODB as an object-oriented database and leave it at
that.

Post by Andreas Jung
As stated a database consists in my definition of the storage layer and a
query layer.
The ZODB is clearly a storage-only implementation without a query engine
(besides the low-level traversal logic).
It clearly lacks any higher level query functionality as it was
implemented as part of the ZCatalog.

This is a fair point with which I disagree. (Although I do wish there was a
standardized catalog implementation independent of any application
frameworks.)

Jim

[tk]

Post by Jim Fulton
I prefer to describe ZODB as an object-oriented database and leave it at
that.

This is the best description I prefer to define ZODB. Thank you Jim. :-)


tk

Post by Jim Fulton
Jim
--
Jim Fulton
http://jimfulton.info

[Andreas Jung]

It is always easy finding additional attribution for giving an existing
technology a new sense.
Let's add a SQL query layer which turns the ZODB into a SQL database. Oh,
we can also store time series
data inside the ZODB and now we have ZODB for time series data.

You got my point. It's all about marketing, honest marketing in particular.

And as you said: the ZODB is not a graph database and it does not solve the
problem that one expects from a graph database if you have the mentioned
solutions in mind.

Peace
Andreas

Post by Jim Fulton
...

Post by Andreas Jung
The ZODB is a transactional, hierarchically organized store for Python
pickles aka object store.

That is incorrect. ZODB does in fact store an object graph. It isn't
limited, no does it depend on hierarchies in any way.
It shares with graph databases the property that graphs are very easy to
represent and use.
While it's possible to represent graphs in relational databases, it is
difficult and inefficient, compared to ZODB in my experience.
I prefer to describe ZODB as an object-oriented database and leave it at
that.

Post by Andreas Jung
As stated a database consists in my definition of the storage layer and a
query layer.
The ZODB is clearly a storage-only implementation without a query engine
(besides the low-level traversal logic).
It clearly lacks any higher level query functionality as it was
implemented as part of the ZCatalog.

This is a fair point with which I disagree. (Although I do wish there was
a standardized catalog implementation independent of any application
frameworks.)
Jim
--
Jim Fulton
http://jimfulton.info

...

[Christopher Lozinski]

There really are different target markets. And those different target markets think different things.

There is the community of computer scientists. They have definitions for hierarchical databases, relational databases, object-oriented databases, and graph databases. It was useful to read the wikipedia definitions of those different types of databases. The ZODB does primarily fall into the Object-Oriented category, although it has a lot of similarities with the hierarchical and even with the graph database. (It has nodes, directed edges and properties but not a query language nor graph theory behind it). So the computer scientists are happy calling it an object database. And have understandable objections to calling it a graph database.

I think that there is another group of people. The average user of relational databases. They are aware that there is a lot of complexity mapping back and forth. They know that they have a “graph" of Python objects. They like the idea of a “Graph Database”. For them it is just a "graph of objects", without the mental baggage that the computer scientists carry with them. Maybe, like me, they have not read the Wikipedia definitions. At the next conference I go to, I will survey the different world views. It will be interesting to see how that market thinks about these things.

In any case, a lot of the computer scientists sit on proposal review boards, and so in the future I will title my talk: “ZODB, the Object Database for Python Developers”. With that change, I will probably get a lot more acceptances. Thank you.

But it is also important to connect with what the average user is thinking. I propose the following description.

“ZODB is an object database implemented in Python and optimized in C. Just subclass off of the persistent classes and your objects, graphs, and applications become persistent.”

I hope that approach will satisfy everyone. Maybe there are some people who only see one point of view, and will not be happy that I used the word graph. We will see.

Warm Regards
Christopher Lozinski

[Joni Orponen]

On Mon, Oct 29, 2018 at 8:40 AM Christopher Lozinski <

Post by Christopher Lozinski
I hope that approach will satisfy everyone. Maybe there are some people
who only see one point of view, and will not be happy that I used the word
graph. We will see.

Never try to satisfy everyone; simply add suitable caveats to statements.
This is an engineering tool not (currently) backed by a company. There is
no direct gain from 'sales'.

[Andreas Jung]

Just stop with these pointless tries to redefine or rename the ZODB. The
ZODB is around for almost 20 years. We have a clear understanding what the
ZODB is and where it should be used for and where not. And something like
"...optimized in C" is pointless. Please stop this marketing nonsense.
There are no new markets for the ZODB. The ZODB is still a solid solution.
But for decent applications with decent requirements regarding
functionality, scalability etc. we have better options than 10 or 20 years
ago. And again, there are no new markets and there are no new
opportunities. Customers don't care about the underlaying data storages in
customer projects, developers don't care much about the ZODB. THat's the
situation. Not much to be added.

-aj

Post by Christopher Lozinski
There really are different target markets. And those different target
markets think different things.
There is the community of computer scientists. They have definitions for
hierarchical databases, relational databases, object-oriented databases,
and graph databases. It was useful to read the wikipedia definitions of
those different types of databases. The ZODB does primarily fall into the
Object-Oriented category, although it has a lot of similarities with the
hierarchical and even with the graph database. (It has nodes, directed
edges and properties but not a query language nor graph theory behind it).
So the computer scientists are happy calling it an object database. And
have understandable objections to calling it a graph database.
I think that there is another group of people. The average user of
relational databases. They are aware that there is a lot of complexity
mapping back and forth. They know that they have a “graph" of Python
objects. They like the idea of a “Graph Database”. For them it is just a
"graph of objects", without the mental baggage that the computer scientists
carry with them. Maybe, like me, they have not read the Wikipedia
definitions. At the next conference I go to, I will survey the different
world views. It will be interesting to see how that market thinks about
these things.
In any case, a lot of the computer scientists sit on proposal review
boards, and so in the future I will title my talk: “ZODB, the Object
Database for Python Developers”. With that change, I will probably get a
lot more acceptances. Thank you.
But it is also important to connect with what the average user is
thinking. I propose the following description.
“ZODB is an object database implemented in Python and optimized in C.
Just subclass off of the persistent classes and your objects, graphs, and
applications become persistent.”
I hope that approach will satisfy everyone. Maybe there are some people
who only see one point of view, and will not be happy that I used the word
graph. We will see.
Warm Regards
Christopher Lozinski

...

[tk]

Good morning Andreas,

You seem a little angry for nothing... I like ZODB because its free
software and a better object-oriented database than Durus mostly. I'm
not interested in upgrading to something else strictly because there is
a market for this thing... In fact I'm always looking for the best open
source softwares possible and the possibility to adapt my softwares
based on what my customers need, not what other peoples are telling me
to use. :-)

kind regards,

tk

Post by Andreas Jung
Just stop with these pointless tries to redefine or rename the ZODB. The
ZODB is around for almost 20 years. We have a clear understanding what
the ZODB is and where it should be used for and where not.  And
something like "...optimized in C" is pointless. Please stop this
marketing nonsense. There are no new markets for the ZODB. The ZODB is
still a solid solution. But for decent applications with decent
requirements regarding functionality, scalability etc. we have better
options than 10 or 20 years ago. And again, there are no new markets and
there are no new opportunities. Customers don't care about the
underlaying data storages in customer projects, developers don't care
much about the ZODB. THat's the situation. Not much to be added.
-aj
There really are different target markets.  And those different
target markets think different things.
There is the community of computer scientists.  They have
definitions for hierarchical databases, relational databases,
object-oriented databases, and graph databases.  It was useful to
read the wikipedia definitions of those different types of
databases.  The ZODB does primarily fall into the Object-Oriented
category, although it has a lot of similarities with the
hierarchical and even with the graph database.  (It has nodes,
directed edges and properties but not a query language nor graph
theory behind it).  So the computer scientists are happy calling it
an object database.  And have understandable objections to calling
it a graph database.
I think that there is another group of people.  The average user of
relational databases.  They are aware that there is a lot of
complexity mapping back and forth.  They know that they have a
“graph" of Python objects.  They like the idea of a “Graph
Database”.  For them it is just a "graph of objects", without the
mental baggage that the computer scientists carry with them.
Maybe, like me, they have not read the Wikipedia definitions.  At
the next conference I go to, I will survey the different world
views.  It will be interesting to see how that market thinks about
these things.
In any case, a lot of the computer scientists sit on proposal review
boards, and so in the future I will title my talk: “ZODB, the Object
Database for Python Developers”.   With that change, I will probably
get a lot more acceptances.  Thank you.
But it is also important to connect with what the average user is
thinking.  I propose the following description.
“ZODB is an object database implemented in Python and optimized in
C.  Just subclass off of the persistent classes and your objects,
graphs, and applications become persistent.”
I hope that approach will satisfy everyone.  Maybe there are some
people who only see one point of view, and will not be happy that I
used the word graph.  We will see.
Warm Regards
Christopher Lozinski
--
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
For more options, visit https://groups.google.com/d/optout.

...

[Andreas Jung]

It's all about (constantly) telling nonsense and doing improper marketing
for things that are just not true..that's the whole point.
Nothing about or against the ZODB or whatever...but promoting a non
existing ZODB "graph database" as a "graph database" is just awkward.

-aj

Post by tk
Good morning Andreas,
You seem a little angry for nothing... I like ZODB because its free
software and a better object-oriented database than Durus mostly. I'm
not interested in upgrading to something else strictly because there is
a market for this thing... In fact I'm always looking for the best open
source softwares possible and the possibility to adapt my softwares
based on what my customers need, not what other peoples are telling me
to use. :-)
kind regards,
tk

Post by Andreas Jung
Just stop with these pointless tries to redefine or rename the ZODB. The
ZODB is around for almost 20 years. We have a clear understanding what
the ZODB is and where it should be used for and where not. And
something like "...optimized in C" is pointless. Please stop this
marketing nonsense. There are no new markets for the ZODB. The ZODB is
still a solid solution. But for decent applications with decent
requirements regarding functionality, scalability etc. we have better
options than 10 or 20 years ago. And again, there are no new markets and
there are no new opportunities. Customers don't care about the
underlaying data storages in customer projects, developers don't care
much about the ZODB. THat's the situation. Not much to be added.
-aj
There really are different target markets. And those different
target markets think different things.
There is the community of computer scientists. They have
definitions for hierarchical databases, relational databases,
object-oriented databases, and graph databases. It was useful to
read the wikipedia definitions of those different types of
databases. The ZODB does primarily fall into the Object-Oriented
category, although it has a lot of similarities with the
hierarchical and even with the graph database. (It has nodes,
directed edges and properties but not a query language nor graph
theory behind it). So the computer scientists are happy calling it
an object database. And have understandable objections to calling
it a graph database.
I think that there is another group of people. The average user of
relational databases. They are aware that there is a lot of
complexity mapping back and forth. They know that they have a
“graph" of Python objects. They like the idea of a “Graph
Database”. For them it is just a "graph of objects", without the
mental baggage that the computer scientists carry with them.
Maybe, like me, they have not read the Wikipedia definitions. At
the next conference I go to, I will survey the different world
views. It will be interesting to see how that market thinks about
these things.
In any case, a lot of the computer scientists sit on proposal review
boards, and so in the future I will title my talk: “ZODB, the Object
Database for Python Developers”. With that change, I will probably
get a lot more acceptances. Thank you.
But it is also important to connect with what the average user is
thinking. I propose the following description.
“ZODB is an object database implemented in Python and optimized in
C. Just subclass off of the persistent classes and your objects,
graphs, and applications become persistent.”
I hope that approach will satisfy everyone. Maybe there are some
people who only see one point of view, and will not be happy that I
used the word graph. We will see.
Warm Regards
Christopher Lozinski
--
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
For more options, visit https://groups.google.com/d/optout.

--
https://www.isotoperesearch.ca
https://www.isotopesoftware.ca

...

[Christopher Lozinski]

Nothing about or against the ZODB or whatever...but promoting a non existing ZODB "graph database" as a "graph database" is just awkward.

I like that we all agreed to call it an object database. Just a reminder,
you made a very similar mistake by calling the ZODB “Hierarchical Storage”.

Chris


On Oct 25, 2018, at 5:00 PM, Andreas Jung <***@gmail.com> wrote:

Of course a hierarchical storage is some kind of graph.

The ZODB is a transactional, hierarchical grave for Python pickles. Point.

[Jim Fulton]

Hi Andreas and Chris,

I agree that ZODB is not a graph database. I have said this many times.

Jim

Post by Andreas Jung
Again, the ZODB is not a graph database. You can store graphs with very
database type. You could store graph information on the filesystem and use
grep for searching on the data. That does not make a storage graph
database. We have build a bunch of project on top of graph databases and
none of them could be implemented in reasonable, scalable and maintainable
way with the ZODB. I appreciate your energy for promoting such an old
technology and the ZODB still has its use cases. But never ever for a
(large scale) graph database. As said: the ZODB does not provide any graph
related query capabilities which are standard and often needed in graph
databases. And the ZODB is not suitable for building arbitrary graph
related solutions in 2018. Storing data is one point of a database, the
capability to query and manipulate data (at large scale) is different
point. The average Python developers should know nowadays about database
options. So promoting the ZODB as graph database on the same level as Neo4J
and others is just absurd.
-aj

Post by Christopher Lozinski
Thank you for the comments. It is most difficult to get good
constructive criticism. So I will go ahead and integrate your comments
into the next version of my talk.
First let me address specific criticisms of the ZODB, and then we will
talk about our different points of view. Forgive me if I first restate
your criticisms more politely. And I will add a few other common
criticisms.
1. The ZODB is a hierarchical database.
This is a common misconception. That is why in my talk I start off
with the canonical Neo4J example, and show how it is implemented in the
ZODB by Graphagus. So that people would understand that the ZODB does
graphs as well as hierarchies. Throughout my talk I kept repeating that
message, that the ZODB also does graphs.
Actually web site URL’s are hierarchical, so if one is building a
website, the ZODB, traversal, and views on objects work great.
2. The ZODB stores data in Pickles.
Well in order to serialize data and store it on the hard drive, you have
to use something. You recommended ArrangoDB.
The database... internally ... uses ArangoDB's VelocyPack – a fast and
compact binary format for serialization and storage.[7]
<https://en.wikipedia.org/wiki/ArangoDB#cite_note-7>
So you think that Velocity Pack is a better choice than Python Pickles?
Indeed my talk was clearly labelled “
For Python Developers.“ In fact I
am just in the
process of debugging a copy command. it uses Python Pickles. Easy for me to debug
entirely in Python. proving that the ZODB is great for Python
developers. If I were to do that in
ArrangoDB, I would need access to a C development tool set.
Thank you for helping me to better understand this particular advantage of the ZODB
over ArangoDB
3. The ZODB does not serve JSON.
And while it is true that the ZODB does not natively include software for converting
an object to json, there are a number of Python libraries which do that. I serve a
number of json files over at PythonLinks.info <http://pythonlinks.info/>
It is easy to serve data however you wish. Even better would be Apache
Avro. There are Python libraries to help me do that. Does ArrangoDB serve
Apache Avro files? I think not.
4. The ZODB is old.
Python also is old. Are you suggesting that we not use Python? I find
that software matures. The most recent version of Python keep getting
better.
The same is true of the ZODB. It is old, mature, well tested. Very
stable and mature. Its api is not constantly changing.
I think of its age as an advantage.
5. The ZODB does not scale.
Just store your data in PostgreSQL and it will scale as well as any database.
6. There is no company behind it.
Well indeed the Zope Corporation went bankrupt a long time ago, but the
open source ZODB continues to be upgraded and improved. What will happen
if Arrango Corporation goes broke? Are you worried about that?
7. The ZODB does not support indices.
Well just write your own, or use NewtDB which integrates the ZODB into
PostgreSQL and their high performance indices.
8. The ZODB does not have edge objects.
Well it does have edges, the references between objects. It does not
have additional properties on those edges. But then I do not need that.
And if you need explicit edge objects, Graphagus added them in 500 lines
of code. Actually at the time, the graphagus benchmarks were faster than
the Neo4J benchmarks. In the meantime, I have no edge objects, and my
code is simpler.
9. The ZODB does not have a query language.
There is a project to add GraphQL to Plone. Zope.interface should make
that quite easy to do. Probably not that hard to add NetworkX or a python
version of Gremlin to the ZODB. Actually as a Python developer, I am quite
happy without a query language. Maybe my life is simpler with everything in
Python. I use innovative Javascript query tools on the client. ArrangoDB
would not help me there.
Did I miss any of the major ZODB criticisms? I will add these to the
next version of my talk.
POINTS OF VIEWS
Now let us get onto the issues of point of view. I targeted this talk at
developers using both Python and a relational database, considering using a
graph database.
I think of myself as a Python developer. I want to make things as simple
as possible. Using the ZODB as a database is so much easier than using a
relational database. That is the focus of my talk.
You are part of a different community You are a seasoned Arrango Graph
database user. You have certain expectations from a graph database. The
ZODB does not meet your needs. I understand that.
I would say that there are two types of databases. Object Graph and
Property Graph. The ZODB is an object graph database. I believe that
ArrangoDB and Neo4J are property graph databases. And yes, the ZODB is
not a property graph database. Nor does it include a query language.
Does that mean that the ZODB is just a hierarchical database? Technically
not correct. Nor are you the language police.
There were a number of other mischaracterizations of my statements.
ZeroDB, although no longer maintained is a very interesting concept. I am
sure that the software still works. That is the advantage of a mature
database. I am sorry that people do not care more about privacy.
Nor did I create a use case for the ZODB as a replacement for Neo4J or
ArangoDB. That was entirely in your mind. My point was that it is really
easy for Python developers to use compared to a relational database.
I am grateful for your feedback. It is always good to be polite. Another
important skill is to understand other people’s points of views. And
finally it is important to support diversity. Sometimes ArrangoDB is a
better choice, sometimes the ZODB is a better choice.
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
For more options, visit https://groups.google.com/d/optout.

...