Whatever approach you take should be easily consumable via Ajax from the
current active generation of browsers...
I'm a fan of domain-specific or source-specific representations (JSON or
XML, doesn't matter) rather than vague, generic structures. JSON and XML
are both quite suitable for containin
FWIW, we store all dates as milliseconds relative to UTC, and pass them
around in that format. We identify the data types of fields/properties in
separate metadata structures embedded in the response, making the returned
content easily parsable and interpretable by relatively dumb clients.
-O
What about:
"data": {"name" : "NeoS::Max"}, "age": {"NeoI::31" }
"data": {"name" : "NeoS[]::Max,Javier,Peter"}, "age": {"NeoI[]::31,29,33" }
On Tue, Nov 23, 2010 at 4:59 PM, Rick Bullotta
wrote:
> FWIW, we store all dates as milliseconds relative to UTC, and pass them
> around in that format.
IMHO, the data types that are not supported by the Neo4j REST API are
Date and Binary data. So it could be a solution add a Neo4j special
dictionary for these cases:
{
"address":
{
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalC
BSON seems to have an Array type as well.
http://bsonspec.org/#/specification
On Tue, Nov 23, 2010 at 7:40 PM, Javier de la Rosa wrote:
> IMHO, the data types that are not supported by the Neo4j REST API are
> Date and Binary data. So it could be a solution add a Neo4j special
> dictionary for
Neo4j REST/Server handles array values:
{ "array-property": [10, 321, 45] }
2010/11/24 Max De Marzi Jr.
> BSON seems to have an Array type as well.
>
> http://bsonspec.org/#/specification
>
>
>
> On Tue, Nov 23, 2010 at 7:40 PM, Javier de la Rosa
> wrote:
> > IMHO, the data types that are not
I was thinking about this...Neo4j doesn't really do Dates. It's Java
Primitives or Strings.
So how about we just establish a convention?
Something like:
Any field ending in "date", "time", "_at", or "_on" is assumed to be a
date (in Unix Epoch milliseconds) and will be converted (from string,
i
Perhaps I'm missing something here, but since Neo4j does not support dates,
then surely neither should the main REST API? If a users application decided
to store dates in strings, then their client code would also already need to
deal with the dates as strings, regardless of whether the client talk
2010/11/25 Craig Taverner
> Perhaps I'm missing something here, but since Neo4j does not support dates,
> then surely neither should the main REST API? If a users application
> decided
> to store dates in strings, then their client code would also already need
> to
> deal with the dates as string
On Thu, Nov 25, 2010 at 07:11, Craig Taverner wrote:
> My vote is to keep the REST API as close as possible to the core Neo4j. If
> dates are added to the core, then add them to the REST API. Until then,
> surely this is an application level issue...
+1.
I wish the Date type were added soon to th
10 matches
Mail list logo
