[tor-bugs] #12030 [BridgeDB]: Create a ORM DatabaseManager for interacting with BridgeDB's database backends

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri May 16 16:06:54 UTC 2014


#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


More information about the tor-bugs mailing list