[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #12030 [BridgeDB]: Create a ORM DatabaseManager for interacting with BridgeDB's database backends
#12030: Create a ORM DatabaseManager for interacting with BridgeDB's database
backends
-------------------------+-------------------------------------------------
Reporter: isis | Owner: isis
Type: defect | Status: new
Priority: major | Milestone:
Component: | Version:
BridgeDB | Keywords: bridgedb-db, bridgedb-dist,
Resolution: | bridgedb-1.0.x, proposal-226
Actual Points: | Parent ID:
Points: |
-------------------------+-------------------------------------------------
Description changed by isis:
Old description:
> We need a `DatabaseManager` which will handle receiving `BridgeRequest`s
> from BridgeDB's distributors, and will
> [https://twitter.com/BigDataBorat/status/360850476150956032 queue these
> requests] as transactions with the backend databases.
>
> The distributors are going to use a common method (just call it
> `getBridgesFromDBManager()` for now) to request `Bridge`s from the
> `DatabaseManager`, and they will expect to receive some relatively well-
> supported, simple, serialised format (probably JSON) in return.
>
> 1. '''The Easy Way''' The ''easier'' way to do this would be to not
> really actually truly make a for-reals ORM, and simply expect to be
> interacting with a NOSQLly CouchDB backend
> [https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/226
> -bridgedb-database-improvements.txt#l82 as described in proposal #226].
> CouchDB documents are JSON anyway, so this is super easy. If we go this
> route, we'll need some code to convert the old SQLly stuff to the new
> NOSQLly format.
>
> 2. '''The Masochistic Way''' The harder, but possibly better in the long
> run (should we ever decide to stop using NOSQL/OODBMSs), way to do this
> would be to write a true ORM/RDBMS which can work with either system.
New description:
We need a `DatabaseManager` which will handle receiving `BridgeRequest`s
from BridgeDB's distributors, and will
[https://twitter.com/BigDataBorat/status/360850476150956032 queue these
requests] as transactions with the backend databases.
The distributors are going to use a common method (just call it
`getBridgesFromDBManager()` for now) to request `Bridge`s from the
`DatabaseManager`, and they will expect to receive some relatively well-
supported, simple, serialised format (probably JSON) in return.
1. '''The Easy Way''' The ''easier'' way to do this would be to not
really actually truly make a for-reals ORM, and simply expect to be
interacting with a NOSQLly CouchDB backend
[https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/226
-bridgedb-database-improvements.txt#l82 as described in proposal #226].
CouchDB documents are JSON anyway, so this is super easy. If we go this
route, we'll need some code to convert the old SQLly stuff to the new
NOSQLly format.
2. '''The Masochistic Way''' The harder, but possibly better in the long
run (should we ever decide to stop using NOSQL/OODBMSs), way to do this
would be to write a true ORM/RDBMS which can work with either system.
This databases which this system will interact with will be used for
storing complex/referential/self-referential/recursive datatypes, such as
`bridgedb.Bridges.Bridge`s and structures for storing data about blocking
events for bridges (including timestamps, discovery method, and country
code of the block, etc.) as defined
[https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/226
-bridgedb-database-improvements.txt#l112 in Section 1.b. of proposal
#226].
--
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12030#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs