48 karma · joined November 20, 2011
(Full disclosure: PM at MarkLogic)
[1] https://github.com/jmakeig/redux-thunk-scaffolding/blob/mast...
For a solution today, MarkLogic is a transactional distributed document database. Cross-document and cross-partition transactions have been a key tenet of the architecture from the beginning (like, 2002 beginning). Take a look at https://developer.marklogic.com/blog/how-marklogic-supports-... for details.
Full disclosure: I’m a Product Manager at MarkLogic.
The findings are intuitive and validate that surge pricing is an overall good thing for the market.(Yea, microeconomics!) However, the cynic in me isn't sure we'd have seen a study that didn't come to that (positive) conclusion.
How does an agreement between an academic and a data provider work to prevent this sort of bias? (In the general case. I have no evidence of that in play here.)
Update: speling
(Full disclosure: I work at MarkLogic)
MarkLogic can handle all of these requirements with aplomb. You can think of MarkLogic as a database built with search engine technology. It uses a document data model (text documents in XML or JSON). Each term (word, phrase, parent-child relationship, etc.) is indexed on ingest. There are index knobs and levers for things like diacritics, wildcards, and scalars, like you'd expect in real search engine.
As for document permissions, they're indexed just like other terms. However, they’re automatically ANDed on to each query in the database engine, not application code. MarkLogic supports role-based permissions (read, write, and execute for stored procedures) with optional Kerberos and/or LDAP auth*n.“Ignored/hidden items” are those that a user doesn’t have permissions to access.
"Followed/watched items" is a pretty common requirement. MarkLogic uses a special "reverse index" to index queries along with text, values, and structures. With regular "forward" queries, queries find documents. With reverse queries, documents find queries. Thus anything that can be expressed in a query can be turned into an alert. This provides some pretty powerful match-making where a document can express its own attributes as well as those it’s interested in matching. Hook that up to a trigger (pre- or post-commit) and you have alerting that scales to billions of documents and millions of queries. One of the world’s biggest news sites uses this infrastructure on a MarkLogic cluster to handle saved searches and alerts.
xdmp:http-get("http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/2.5_month.geojson")
or in the upcoming release, you'll be able to do the same in server-side JavaScript (embedded V8): xdmp.httpGet("http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/2.5_month.geojson");
(Full disclosure: I’m a Product Manager at MarkLogic.)I find this really convenient for quickly standing up web services and doing ETL-type logic that runs close to the data in the database.
If you can relax the decoupling or independent evolution constraints, RPC over HTTP is usually easier to understand and implement. This is where most HTTP APIs fall. (…and that’s OK)
I do look forward to the JSON community (re?)developing schema and transformation languages to go along with this.