Hi Stephan
There's a huge graphic
reading "Core data store engine - 64-bit - Unicode - multi-threaded -
multi-process - replication - synchronization". I wonder what that
means, because none of these terms are specific to NoSQL.
Well i admit this is not the nicer we could have made.
We made this big picture because we realized that each time we were
talking about our project, people were immediately thinking that it
had to provide SQL code, they had difficulties to understand these
points :
- a database can use internally an other language than SQL
- No this solution can not be used over your MySQL, or Oracle database
In fact it could it but with complex SQL requests generation and it
would loose most of its performance instead of gaining power ;-)
The list of
key objectives above the graphic also sounds quite obvious, and could
probably be used to promote any random technology (for example, "As
companies grow, the requirements of applications may change").
This list sounds obvious even more today and NoSQL solutions are a
collection of different technologies to address these objectives each
with their own priorities
This post could not have listed all existing tools (NoSQL and
others),
its purpose was to expose the targeted objectives and how this one
solution (Wakanda) intends to address them
As you noticed we tryed to make an article understable by any one with
a minimum of development skills
Is there a plan to make your database available on other platforms?
Webkit is growing, but as of now only a small percentage of clients can
use it.
We looked at all major JavaScript engines and it was the most adapted
technically and its community is very active. We are confident to
have
a full implementation of ECMAScript 5 quite quickly. We first looked
at
Server-side requirements
The level of client-side compatibility is a bonus, as we can't afford
to ignore other browsers
Note that even if it's not the most widely use on desktops, It is the
first one on mobile platforms including of course iPhone and Nokia
mobiles
I'd be interested to hear more about what you're proposing, and I'd be
even more interested in some technical details, example code, thoughts
about portability, etc.
All of this is coming. We're actually working on a new website with
technical details, demos, API documentation...
I can say that we always look to existing APIs before building ours
trying to perform the most effective code portability as possible
We support the CommonJs Module API and also some W3C / HTML5 APIs
To start with a small example (the one given in your article):
var jobOffersWithMary =
ds.employees(‘MyName’).manager.daughter.company.jobOffers.count();
That looks very nice and easy on the surface, but what if my manager
doesn't have a daughter? What if she's unemployed? What if I'm
interested in my manager's dog instead? (not romantically!) What
properties does a manager have? Does he have a son, a lawyer, a couch, a
garden, ...? As soon as you venture into the everything-can-be-connected
terrain, you'll be using lots of if-else branches (or try-catch), and
then the code won't look so pretty anymore.
You can imagine that this is just a funny example of code ;-)
Each of these chained objects inherits from native methods and
properties
like "getModel" or "getName" enabling more generic code when required
When you go through this "terrain", you do it because you know the
context,
for example from filters you applied on the collection of objects
you're
working on
I'll be happy to show more use cases using collections, sub
collections, and
specific filter types
And don't forget that ES5 provides getters and setters which gives
huge
possibilities ;-)