Mongo Entity provides developers with entity and controller classes for storing entities entirely in a MongoDB collection. It eliminates the need for a base table, or any SQL queries at all; an entity's ID, name, properties, and any field data are all written directly to MongoDB. It also provides classes for embedded entities: entities that are stored as subdocuments in a parent collection, but that can be managed using the standard Entity API CRUD methods, as well as found with EntityFieldQuery. Ultimately, loading a parent entity should automatically load and embed all its child entities, with only one query to a single MongoDB collection.
Mongo Entity is for developers. It provides no interface, nor does it alter the behavior of existings sites out of the box. Modules can use the provided MongoEntity and MongoEntityController classes in hook_entity_info to store entities in MongoDB, rather than a SQL database.
- Minimal configuration. Save custom Entities entirely in automatically generated MongoDB collections. No SQL tables needed.
- Performance boost. Field data is stored with the Entity in MongoDB, reducing the need for complex JOINs and multiple database queries to load a single object.
You don't even want to know. Really, you don't.
Ok. Well. If you insist.
The goal if this project is to write a functional storage backend using IRC as the transport layer and MongoDB as the database (perhaps IRNOSQL would be a better name).
This is going to scale so hard.
A big thank you to Fernet Branca for sponsoring the development of this module
What this Module does for you:
DBinfo adds a small status report item to the /admin/status/reports page of your Drupal website.
DBinfo tells you the database connection information for any configured databases Drupal has connection info for. Optionally, it can test the connection on status report page load.
This module requires Ctools in order to generate the collapsible reports.
As a security precaution the db password always displays as [omitted] from the report page.
All other database information is considered administrator level knowledge.
Feature requests, issues, patches are all welcome.
The Postgres Signature module making all database connections and queries "personalized". If you have not only default database user but also SQL users with the names as Drupal users, all requests would be performed with corresponding SQL-user name.
Queries from user #1 and from anonymous users authored by default connection string.
Adding and removing Drupal users also leads to do the same on database level.
On administration pages there is a functional to create (or delete) in bulk SQL users to reflect existing Drupal users.
Supports PostgreSQL database only. Currently working on a production system with PostgreSQL version 9.1 .
Installation and usage
Install as a regular module, then visit administration pages under admin/config/people to tune default user creation command.
If needed, prior to module removal you may visit admin page and do bulk remove of SQL users which you do not need anymore.
Supported by Druler.
The Hypertable module provides API access to Hypertable. The API integrates database functionality using the Thrift Library and Hypertable's query language (HQL). The Hypertable module provides a library to build additional functionality or applications.
The hypertable_nodes and hypertable_users modules are sample implementations for how to use the Hypertable API to map node and user entities in addition to performing queries and displaying results from Hypertable.
For instruction on how to set up Hypertable before installing this module visit the Hypertable installation documentation.
As per the requirement I am responsible for developing the core Integration between the Drupal with diffrent technologies.
I contributed in developing generic API for Integration.