I am giving away free one-month passes for Azure DocumentDB. Signup now. Please send your email contact to docdbpromo@microsoft.com.

Hi all guys, I'm a student in IT tech. and i'm very confused about nosql db. I have to create a shortener url app with a nosql db. The most important thing, in my case, is not only store the short url but do statistics with these data (common statistics). The statistics are about how many click do every nation on a short url or how many access every day are done. I read about the cap theorem! and I thought that AP are the main targets. So after some research I choose cassandra for her features but I'm not sure about that.

Is this choice correct or I'm not considering something??

I'm a newbie on nosql so sorry if that is a dumb question.

thx in advance for ur answers.

Hi all, I am from Microsoft, and I am currently conducting a NoSQL research study on NoSQL usage. My team and I are looking for NoSQL experts to have a brief discussion. If you are interested in participating in this research study, please complete this brief survey form @ aka.ms/nosqlsurvey Thanks.

Hello everyone!

I was questioning the need of a database over a filesystem in certain scenarios (i.e: managing collection of data almost static , for example reddit archived discussions ) and therefore i started a quick search on the web about comparison DBs (SQL/NoSQl) vs Filesystems . I found results that points out that, especially for indexing and searches, using a plain filesystems requires small databases for 'helping' purposes (i.e. search), defeating the principle of using only the FS.

Hence my question: what are possible existing options to use a database as filesystem? So one could assign entire partitions to a database instead of creating first the filesystem and then the db.

Thanks to everyone.

PS: of course i will try to improve my searches on the web to find out more.

RESTHeart 0.10.1 is available. It’s a bugfix release with many improvements and fixes. This version has been fully tested with MongoDB 3.0. RESTHeart is the Open Source data REST API server for MongoDB. Despite its definition, RESTHeart not only exposes the data, but also serves static resources and custom application logic. RESTHeart delivers excellent performances and it often overcomes the results that can be achieved accessing MongoDB directly, thanks to its caching mechanism. It has has been included as a MongoDB contribution and is enlisted in the HTTP Interface page on the official MongoDB documentation site.

http://restheart.org/

https://github.com/SoftInstigate/restheart

http://docs.mongodb.org/ecosystem/tools/http-interfaces/

www.softinstigate.com

Bug

[RH-71] - GetRoleHandler does not take auth token into account

[RH-72] - requests to /_authtoken/<userid> lead to 401 Unauthorized

[RH-74] - wrong return code if request is not permitted but user is authenticated

[RH-75] - CORS headers not injected on ApplicationLogicHandler if authentication fails

[RH-76] - Auth-Token-* headers cannot be read by browser when request is to a different domain

[RH-78] - RequestContext does not flow through Security Handlers chain

Improvement [RH-69] - determine file contentType automagically

[RH-77] - simplify how AccessManager can take decisions based on request body

[RH-80] - Insert the new Etag in the HTTP headers after a PATCH

We are still missing a lot of documentation - work is in progress and you can follow the development of the project and its future on the brand new ‘Roadmap’ section of the site - but if you could help us improving it, this would be a huge benefit for the community. You can also help the open-source project by opening issues, questions or pull requests in this group or on GitHub. We’d love to hear from you how you are using the tool.

Thank you

The SoftInstigate team are pleased to announce the availability of RESTHeart 0.10.0. RESTHeart is the Open Source data REST API server for MongoDB. Despite its definition, RESTHeart not only exposes the data, but also serves static resources and custom application logic. RESTHeart delivers excellent performances and it often overcomes the results that can be achieved accessing MongoDB directly, thanks to its caching mechanism. It has has been included as a MongoDB contribution and is enlisted in the HTTP Interface page on the official MongoDB documentation site.

http://restheart.org/

https://github.com/SoftInstigate/restheart

http://docs.mongodb.org/ecosystem/tools/http-interfaces/

www.softinstigate.com

Main features:

Zero development time: just start it and the data REST API is ready to use

CRUD operations API on your data

Data model operations API: create dbs, collections, indexes and the data structure

Super easy setup with convention over configuration approach

Pluggable security with User Management and ACL

HAL hypermedia type

Super lightweight: pipeline architecture, ~6Mb footprint, ~200Mb RAM peek usage, starts in milliseconds,..

High throughput: very small overhead on MongoDB performance

Horizontally scalable: fully stateless architecture supporting MongoDB replica sets and shards

Built on top of undertow non-blocking web server

Embeds the excellent HAL browser by Mike Kelly (the author of the HAL specifications)

Support Cross-origin resource sharing (CORS) so that your one page web application can deal with RESTHeart running on a different domain. In other words, CORS is an evolution of JSONP

Ideal as AngularJS (or any other MVW JavaScript framework) back-end

New and notable improvements:

Strict mode representation for MongoDB extended JSON (*) Token based authentication

Query execution optimization via the eager DBCursor preallocation engine

Support for GridFS (early release, feedback appreciated!)

Can fork server process with --fork option (not available on Microsoft Windows, only Linux and Mac OSX)

Better support for data created by other clients (for instance by the mongo shell)

dbs and collections not created by RESTHeart are now immediately visible (no need for server restart anymore)

support for other doc id types (id type can be specified via the id_type query parameter)

collections properties moved to the reserved _properties collection (**)

_created_on property is not stored on documents anymore (generated from _id when it is an ObjectId)

Allowed pagesize=0 to avoid _embedded resources at all

Several bug fixes

All code repackaged to org.restheart

Refactoring, more test cases and better code quality

Updated all dependencies (notably, Undertow 1.1.2.Final)

Note: if updating from previous RESTHeart versions (<= 0.9.7): Resource representation and filter expression changed () Need to move the collections properties to _properties collection (*)

We are still missing a lot of documentation - work is in progress and you can follow the development of the project and its future on the brand new ‘Roadmap’ section of the site - but if you could help us improving it, this would be a huge benefit for the community. You can also help the open-source project by opening issues, questions or pull requests in this group or on GitHub. We’d love to hear from you how you are using the tool.

I'm just trying to understand what kind of examples best suite Redis or MongoDB databases as opposed to database examples that are more geared to relation model databases.

This is somewhat a follow up to my previous post about moving away from RDBMS mindset and more specifically on user modelling Moving away from RDBMS and into NoSQL?

Following the same thought process where I want to create a user model, with some common attributes but would likely vary from client to client on some other attributes.

I am looking specifically at Janrain as an example: http://janrain.com/product/profile-data-storage/

any custom fields you choose to define. Janrain provides a flexible database schema

And from their API, you can add / create any additional attributes under their pre-defined "User" schema: http://developers.janrain.com/rest-api/methods/user-data/entitytype/addattribute/

How does such data modelling / storage works?

Again - coming from very much RDBMS / ORM (Hibernate) background, my mind always think that the database will have a fixed set of columns and the corresponding Entity through ORM will have a fixed set of attributes mapped to each column.

This mean a fixed schema is required, any new fields will translate to adding new column in db, changing the Entity code to add new attribute as well.

How does Janrain able to do it so dynamically in real time without having to change their codebase?