Code

Opened 3 years ago

Closed 3 years ago

Last modified 22 months ago

#14686 closed Uncategorized (wontfix)

ORM support for VoltDB

Reported by: sylverb Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords: database, voltdb
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Hello,

Would be great to have ORM support for VoltDB DBMS.

They've released a native Python driver and it's a very promising DB which is a mix between NoSQL & relational SQL. The database retains the data in RAM and distributes both the data and the SQL engine which processes it, across the server or server cluster's processor cores. VoltDB is designed to ensure transactional consistency while eliminating legacy overhead.

In short it's designed for the Web and takes care of sharding while still using SQL as a query language.

SB

Attachments (0)

Change History (7)

comment:1 Changed 3 years ago by sylverb

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 3 years ago by lrekucki

  • Resolution set to wontfix
  • Status changed from new to closed

You should probably see this django-dev thread (which was about some other DBMS, but I think it applies). In short, Django encourages you to create 3rd party database backends and doesn't plan to include any more backends in the core at the moment.

comment:3 Changed 22 months ago by neokeats

  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized
  • UI/UX unset

hi,

is there somewhere a wiki regrouping thoses 3rd party database backend arbitrarily excluded ?
in order to know if someone have provided a solution.

nosql have a branch because it's a completly different concept...

but haven't found anything related to django+voltdb.

thanx

comment:4 follow-up: Changed 22 months ago by russellm

The exclusion wasn't "arbitrary" at all. Django has a database backend API for a reason -- so that we don't need to be the maintainers for a thousand database backends. We officially support the 3 most popular open source databases, and one very high profile closed source database.

NoSQL has a branch because it was a Google Summer of Code project, and it would have required significant architectural changes internally to make a NoSQL backend possible. However, it's important to note that that branch *didn't* proposed to add any new database backends. It was primarily a series of internal changes that would make a third-party NoSQL backends possible.

As for a list of external DB APIs -- the only list I can point you at is in the docs. We don't really have a firm set of guidelines for what gets on this list; a rule of thumb would be "a backend that someone is willing to state actually works in anger".

comment:5 in reply to: ↑ 4 Changed 22 months ago by kmtracey

Replying to russellm:

a rule of thumb would be "a backend that someone is willing to state actually works in anger".

Works in anger?

comment:6 Changed 22 months ago by Alex

It's a play on "fire in anger" (http://en.wiktionary.org/wiki/fire_in_anger), basically meaning "really works under real circumstances"

comment:7 Changed 22 months ago by kmtracey

Ah, thanks. Never encountered that idiom before...

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.