Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The project appears idle, can I take over? #112

Open
freemo opened this issue Dec 19, 2019 · 10 comments
Open

The project appears idle, can I take over? #112

freemo opened this issue Dec 19, 2019 · 10 comments

Comments

@freemo
Copy link

freemo commented Dec 19, 2019

Hi. Been starting to use this project in my own but find it lacks some very important features (like transaction support or using up to date dependencies) and has been mostly idle for 1 - 2 years now.

I'd like to bring the project up to date and improve the feature set before I start using it in my own project. The features I need would also be pretty critical to me moving forward.

So I'd like to ask, any chance I could take over the project as a new project owner? I dont mind forking the project and renaming it, that would of course make things easier since I wouldnt have to maintain backwards compatibility. But I'd be happy to take over the project as-is and maintain BW so it benefits everyone if preferred.
@freemo freemo changed the title The project appears idle, canI take over The project appears idle, can I take over? Dec 19, 2019
@davebshow
Copy link
Owner

davebshow commented Dec 19, 2019 via email

@freemo
Copy link
Author

freemo commented Dec 19, 2019 via email

@freemo
Copy link
Author

freemo commented Dec 20, 2019 •
edited
Loading

Side note (ill repost this on the relevant ticket as well). The fork I have going locally adds transaction support though likely not in the way the original ask intended, but I think the only elegant way possible given the underlying gremlin implementation.

Basically I took advantage of the fact that the only way to get a traversal is either 1) use the raw driver and pass text-based traversals through it (unless im mistaken this is impractical for an OGM, though maybe I'm missing something). 2) Treat each traversal itself as its own transaction and accept that you cant manually create transactions that spread across multiple invocations of traversals (this appears to be the official answer)

So I decided to exploit feature #2 and implement a sort of optimistic locking that works with one caveat, it is only useful when adding new edges and nodes it isnt useful for modifying them in place. This may seem like a big caveat, and it is, but it also is useful when along side another feature I implemented: per-element immutability. In that case if an element is set as immutable then it can be created, but never destroyed nor modified after its initial creation.When these two new features I added are used in tandem you basically get something that is basically optimistic locking that works on immutable graphs.

Let me explain further. Its very typical in immutable graphs that you still need to maintain integrity. This means that a single node or edge may be inconsistent on its own and only makes sense when connected in a valid pattern, a simple example being a graph that must be connected to be valid. As such you may want to create a set of edges and nodes but with the guarantee they either all get created or none of them. Thus the optimistic locking I mentioned.

How it works:

I created a new attribute on Element classes called __immutable__ which takes an enum that has one of three values: {OFF, SIMPLE, TRANSACTIONAL}. When the value is OFF it behaves classically, this is also the default value if nothing is set. SIMPLE only creates immutability but makes not transactional guarantees. TRANSACTIONAL gives the combined functionality of both I mentioned. When this mode is set then transactions occur automatically through the flush method. Whenever a flush occurs a randomly generated UUID is created as a transaction identifier. Then all element updates throw an exception and only allow element creation. When being created every element is given a property called "dirty" which contains the transaction ID. If all saved elements succeed to write to them database then a final traversal is called, written especially a single traversal, which will drop the property dirty from all elements where the ID is matched, this effectively makes the edges and nodes live. However if an exception occurs a rollback traversal is called which drops all the dirty elements.

Finally at startup the system can call a method which scans the DB for any dirty values that may be left over from a crash and removed them as well.

Using this mechanism I was able to get guaranteed DB integrity. So far its only used in single-application-single-database configuration. But I plan to adopt it for multiple application front ends. For that I'd need to do some integrity checking as part of the commit traversal.

I can pull out the code for this if you are interested, right now its just something i use locally.

@dekoza
Copy link

dekoza commented Aug 13, 2020

Anything changed over the past months? I'd love to see this lib alive again and updated to support gremlinpython 3.4

@freemo
Copy link
Author

freemo commented Aug 13, 2020 via email

@dekoza
Copy link

dekoza commented Aug 25, 2020 •
edited
Loading

@freemo I'm sorry but your GitLab instance is failing. Is there any chance for a github mirror?

Also, the documentation is very lacking and sourcecode has confusing docstrings. There are also issues with from_dict methods and default param for Property. I'd love to post a PR but... your GitLab instance is failing.

@freemo
Copy link
Author

freemo commented Aug 25, 2020 via email

@freemo
Copy link
Author

freemo commented Aug 25, 2020 via email

@dekoza
Copy link

dekoza commented Aug 26, 2020

@freemo thank you! The last question is - should I send PRs to gitlab only or is github also OK?

@freemo
Copy link
Author

freemo commented Aug 26, 2020 •
edited
Loading

@freemo thank you! The last question is - should I send PRs to gitlab only or is github also OK?

@dekoza Gitlab is technically the official spot since its where I have all the CI setup. I will accept PR on github but its extra work/steps for me so I do prefer if you do it on gitlab if your willing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dekoza @freemo @davebshow