Lmst

I'm thinking that regarding Doxstorr, granular control of ACID behaviour would make sense in the context of transaction execution and not so much on a per-query basis.

If anybody knows any document databases that let you have extremely granular control of ACID-ity, please let me know!

#rserv #doxstorr #python #foss #documentdb #database

This approach also allows for future refinement, such as adding more granular levels or even allowing per-transaction ACID levels for extremely fine-tuned control in advanced use cases.

Take that, Mongo! 🤣

#doxstorr #rserv #python #foss

What's next in store for Doxstorr:
Making performance trade-offs a configurable setting with four levels of ACID compliance (or three! if relaxed compliance/non-compliance is not considered a level of ACID compliance :-)

RELAXED (Level 0):
Minimal ACID guarantees
No forced disk writes
No transaction logging
READ_UNCOMMITTED isolation
No upfront lock acquisition
No rollback on failure

BASIC (Level 1):
Basic ACID compliance
Transaction logging (but no forced flush)
READ_COMMITTED isolation
No upfront lock acquisition
Basic rollback on failure

STANDARD (Level 2):
Standard ACID compliance
Transaction logging with soft flush
REPEATABLE_READ isolation
Upfront lock acquisition
Full rollback on failure

STRICT (Level 3):
Full ACID compliance
Transaction logging with forced disk writes
SERIALIZABLE isolation
Upfront lock acquisition
Full rollback on failure

#rserv #doxstorr #python #graphdb #foss

from enum import Enum

class ACIDComplianceLevel(Enum):
RELAXED = 0 # Minimal ACID guarantees, maximum performance
BASIC = 1 # Basic ACID compliance, good performance
STANDARD = 2 # Standard ACID compliance, balanced performance
STRICT = 3 # Full ACID compliance, prioritizes data integrity

class DoxStorrConfig:
def __init__(self, acid_level: ACIDComplianceLevel = ACIDComplianceLevel.STANDARD):
self.acid_level = acid_level

class EnhancedFilestore:
def __init__(self, config: DoxStorrConfig):
self.config = config
self.transaction_manager = TransactionManager(self.config)
self.journal = Journal(self.config)

This is also a very preliminary alpha, super early peek into what I hope will eventually become a pluggable document store for rserv. Fittingly called doxstorr.

With ACID!

https://github.com/ha1tch/doxstorr

#rserv #doxstorr #python #foss

Sulpher is the little subset of Cypher (Neo4j's query language) that I'm working on.

I added nore examples of queries that can be expressed in Sulpher:
https://github.com/ha1tch/rserv/blob/main/manual/rserv-manual_0.3.9-part3-basicgraph.md

Here are other graph features that can be accessed via the REST api without need of Sulpher (tSome of these endpoints translate your REST request to Sulpher under the hood)
https://github.com/ha1tch/rserv/blob/main/manual/rserv-manual_0.3.9-part4-graphoperations.md

In the Misc section there's a bit more interesting code example on how to use these graph things from your own Python application, or from wherever you can hit a RESTful http api. It implements the basics to access the graph data of a group of bloggers, with blogs, posts, tags, and comments.

https://github.com/ha1tch/rserv/blob/main/manual/rserv-manual_0.3.9-part6-misc.md

Hope somebody finds it useful!

#rserv #python #graphdb #foss #sulpher #cypher #neo4j

In more than one way.

#rserv #python #graphdb #foss

Today was a good day.

#rserv #python #graphdb #FOSS

.2. Advanced Relationship Handling (direction, multiple types):

MATCH (alice:User {name: "Alice"})-[r:FRIENDS|COLLEAGUES]->(user:User)
RETURN user.name, type(r)

Finding users who are both friends and colleagues of Alice.

#rserv #python #rest #graph #graphdb #cypher #sulpher #neo4j

Variable-length path expressions:

like, for example:

MATCH p=(alice:User {name: "Alice"})-[*..]->(user:User)
RETURN user.name

Finding all users connected to Alice, regardless of the path length.

#rserv #python #rest #graph #graphdb #cypher #sulpher #neo4j

I'm expanding Sulpher (the little subset of Neo4j's Cypher I came up with) to be able to build more interesting graph queries.

Here's where it's at now:
https://github.com/ha1tch/rserv/blob/main/manual/rserv-manual_0.3.9-part3-basicgraph.md

What's next:

Variable-length path expressions
Advanced Relationship Handling (direction, multiple types)
More comprehensive Property-Based Filtering
Advanced Aggregation Functions and Clauses (WITH, ORDER BY)
Parameterisation

#rserv #python #rest #graph #graphdb #cypher #sulpher #neo4j #FOSS

If you're interested in the earlier basic features, here's is an outdated manual of the 0.2.x pre-release

https://drive.google.com/file/d/1lMmGyDT4H07Q4KA-1Q4OZN5qG_qAtQFg/view

#rserv #python #REST #FOSS

I'm working on rserv 0.3.8

https://github.com/ha1tch/rserv/blob/main/manual/rserv-manual-part5-graphs.md

Since 0.3.x rserv has incorporated certain graph-like features that allow you to query data from a property graph perspective.

Any document stored in rserv for any given entity can now be treated as a node from the graph-like perspective.

In order to perform graph queries, I added Sulpher, which is a funny name for a reduced subset of Cypher (the Neo4j query language).

Now I'm more happy with the general design (and keeping it RESTful! unlike GraphQL!) I think I will be ready to make the first public release soon.

#rserv #graphdb #graph #documentdb #cypher #python #REST #FOSS

I dedicated a little time to build rserv, a simple prototyping RESTful server, with some interesting features. Here's the feature set and potential use cases, compared to other options.

It's very beta at this time, let me know if you are interested. FOSS, obviously.

#rserv #REST #dev #webdev #python #FOSS

I dedicated a little time to build rserv, a simple prototyping RESTful server, with some interesting features. Here's the feature set and potential use cases, compared to other options.

It's very beta at this time, let me know if you are interested. FOSS, obviously.

#rserv #REST #dev #webdev #python #FOSS

#rserv

Client Info