The curl bug I ran into is known - number 30 on the list of known curl
bugs...
http://curl.haxx.se/docs/knownbugs.html
I just guessed on how to work around it. My workaround has no
side-effects for my usage. But it was kind of surprising and annoying...
On 12/18/2013 01:18 PM, Wes Freeman
Issue created: https://github.com/neo4j/neo4j/issues/1743
On 12/18/2013 01:18 PM, Wes Freeman wrote:
> I think so, on the issue.
>
> // compatible with back until 1.8 and maybe earlier... will return
> fast as long as there aren't millions of empty nodes at the beginning
> of the file
> start n=no
Your query is essentially the same as my original query -- which was
also in that source file.
I would expect that there is often at least one node initially created
that hangs around forever.
Of course, in my test databases, I clean them out and start over before
each test -- so I have thousands
I think so, on the issue.
// compatible with back until 1.8 and maybe earlier... will return fast as
long as there aren't millions of empty nodes at the beginning of the file
start n=node(*) return n limit 1;
Wes
On Wed, Dec 18, 2013 at 3:11 PM, Alan Robertson wrote:
> Should I open an issue
Should I open an issue on this?
On 12/18/2013 11:47 AM, Wes Freeman wrote:
>
> And yeah you're right, ::1 doesn't work in the config file (which is
> odd), but if you bind to :: you can connect to ::1. Just tested with
> my go driver using the following connection string:
>db, err := sql.Open
Thanks for the experiment. It's always better to try things than to
theorize...
There is no such thing as a perfect monitoring test... But the general
idea is to test as much as you can -- as cheaply as you can - so you can
afford to run it frequently.
One interesting thing about the OCF resour
I tried it with a USB key... just to see. Started neo4j server, made a few
queries, and unplugged the drive unsafely.
If you have RETURN 1; cached in the query cache it seems to continue to
work after unplugging the drive (doesn't work if not cached), in addition
"RETURN X" where X is any number c
True, but it's possible for other queries to not touch the datastore as
well. Would be interesting to try to break it and see what happens.
Unplug a disk to see if neo still responds to read queries that are still
in the cache. :)
And yeah you're right, ::1 doesn't work in the config file (which i
I meant to say "::1". Right now, it won't hear local only ipv6
connections...
But your suggested query doesn't have to touch the data store at all.
Right?
I would assume that either of the others I gave would touch the data
store, and would typically fail of the data store was hung or broken...
You can make it listen on :: if you set it in neo4j-server.properties:
# Let the webserver only listen on the specified IP. Default is localhost
(only
# accept local connections). Uncomment to allow any connection. Please see
the
# security section in the neo4j manual before modifying this.
org.neo
Thanks for the explanation. I have always (mistakenly) thought of the
type of the relationship as a sort of property.
In any case, the script seems to work quite nicely, and is easy to
autogenerate the parameters for from Assimilation discovery information.
I discovered something surprising (a b
return type(r)
Empty curly braces mean no props
Sent from mobile device
Am 18.12.2013 um 06:41 schrieb Alan Robertson :
> The query in the script below produces the following output:
> {"results":[{"columns":["one","rel","two"],"data":[{"row":[{"domain":"metadata","nodetype":"CMAclass","name":"
So, you have two options. You can change it to return type(r), or you can
tell the transactional endpoint you want a more verbose output.
http://docs.neo4j.org/chunked/milestone/rest-api-transactional.html#rest-api-execute-statements-in-an-open-transaction-in-rest-format-for-the-return
1)
https:/
The query in the script below produces the following output:
{"results":[{"columns":["one","rel","two"],"data":[{"row":[{"domain":"metadata","nodetype":"CMAclass","name":"HbRing"},{},{"domain":"metadata","nodetype":"CMAclass","name":"CMAclass"}]}]}],"errors":[]}
What I noticed is that the relation
14 matches
Mail list logo
