scrapper / perobs Goto Github PK

In the code in the redme, you said "merry", I think you meant "marry".
Other than that. What a great idea. I am currently using ZODB on Python, but sadly Python only supports one thread at a time. Maybe now there is shared memory between processes.

In general, I am moving away from Python, just as it is becoming the most popular language, ruby has a much better multi-processing story. Most needed now. But I do need to model trees and graphs. Not sure what I am going to do.

I wish I better understood why Python gives a slightly more elegant persistent object graph model than ruby. The problem is I do not yet know the internals for ruby.

First of all thank you for this great work. The idea of a persistent graph of Ruby objects is a very important concept, and it was the one thing that Ruby lacked. It was the one thing holding me back from ditching Python and moving to Ruby. Now I see a path forward.

I am a Python/ZODB developer, who is increasingly moving to Ruby. The thing that Python lacks is simultaneous multi-threading. What Python does have, and Ruby lacks, is the ZODB.

ZODB gives you a very clean and mature model of a graph of persistent objects. You can either store ZODB objects in FileStorage, or in RelStorage. RelStorage is very heavily used and quite mature.
https://dev.nextthought.com/blog/2019/11/relstorage-30.html

The ZODB object model is a bit cleaner than PerObs. I think PerObs can learn a lesson from ZODB. ZODB does not really use proxy objects. Instead the proxy/ghost objects load the content and become the object.

How does ZODB achieve such a brilliant persistent object abstraction? The magic is in class persistent.

https://github.com/zopefoundation/persistent/blob/master/persistent/persistence.py

Why is there a difference between Ruby and Python? (This problem kept me up for 2 hours last night) Well Ruby and Python are a bit different. Python provides a getattr and setattr method which ZODB overrides to load the data if needed. Ruby does not have that. Each attribute has its own getter and setter methods. So to do this in Ruby one would have to rewrite all of the getter and setters.

I think we could do that automatically. When first loading the application, we could rewrite all of the getters and setters, to use the ZODB persistent Ghost model. Then we would have a gorgeous persistent object model in Ruby.

The other thing the ZODB community would want, is a way to use the persistent ruby objects. It would be quite easy to store Ruby Objects in FileStorage or RelStorage. Right now ZODB objects are serialized with Pickle, but they could be easily serialized with another format. Json is one obvious option. VelocityPack for ArrangoDB has a great reputation. The convert command could move them to that format. Then we could all use our persistent Python objects in Ruby! Hurrah!

So I think I can get fully transparent persistent objects in Ruby. I think I can share them with the Python objects in ZODB. And then eventually we can figure out how to use Ruby’s 3.0 concurrent threads.

As a prerequisite to complete Package postrunner for Debian #27, perobs needs to be packaged for Debian first.

Just like with the issue linked above, my intention is to make this happen. The almost two weeks which have passed between posting that first ticket and this one gives an indication that this might take a while, as my priorities are set to merely allow working a bit on this while my Garmin watch is charging. Although eventually we should get there.

To avoid potential duplication of effort, this ticket is filed to:

• Ask whether @scrapper or anyone else has knowledge about an already started packaging effort?
• To track the progress of my attempt at the task.