I realize I had to compile the RDF component against the current Meta Model
component. There are some breaking changes in Meta Model that require
modification in the RDF component. Validator.java needs to be looked into,
since MetaModelRelationships have been split off of MetaModelProperties.
It does, doesn't it ;-)
And I'm trying to keep the "code" as simple as possible...
.. because for really complex things I think that uploading real code to the
server and mount it on a separate URI in the REST server would be more
efficient ...
-tobias
On Thu, May 20, 2010 at 9:05 PM, Rick Bull
The title should of course be Lookup property range.
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j.org
> Date: Thu, 20 May 2010 21:17:05 +0200
> Subject: [Neo] Lookup property name
>
>
> When trying to add a statement with the RDF model, using the latest version
> of meta model (the
When trying to add a statement with the RDF model, using the latest version of
meta model (the one I have been working on), I get the following error message:
Exception in thread "main" java.lang.NoSuchFieldError: LOOKUP_PROPERTY_RANGE
at
org.neo4j.rdf.store.representation.standard.StandardA
Sounds a lot like "code" ;-)
Rick
-Original Message-
From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On
Behalf Of Tobias Ivarsson
Sent: Thursday, May 20, 2010 2:55 PM
To: Neo user discussions
Subject: Re: [Neo] Transactions in Neo4j REST Server
Hi buddies!
My vo
The code is available as an experimental branch at
https://svn.neo4j.org/components/index/branches/new-index-api/ and its
integration with the kernel is in the branch
https://svn.neo4j.org/components/kernel/branches/new-index-api/
And again, this is just a laboratory branch at the moment.
2010/5/
Hi buddies!
My vote is for adding support for posting a batch of operations to be
executed within the context of one transaction. What we need to figure out
is how these should be expressed. Starting from a list of requirements is
usually a good idea. The features I can think of that the batch ope
Thank you all for the supplied use cases you've shared. By the looks
of it there indeed seems to be cases where indexing for relationships
is a nice fit.
As Tobias mentioned earlier there's some lab code which I've been
trying out and which makes the indexes more expressive and it also can
index r
I am in a situation where being able to bulk upload an ntriples-like
file or perhaps a large JSON data blob via the REST interface as a
single transaction would be incredibly helpful. Consider this a feature
request. Thanks for your work on this!
Cheers.
Kevin
On 5/20/10 6:14 AM, Jim Webber
Hi, Jim.
I'm saying the same thing as you, albeit in a slightly different way.
Whether a "workflow" or "unit of work", the transaction needs to be
identifiable via a unique resource (URI) that provides the context for
related invocations of other services and, of course, for completion and
cleanup
On 7 May 2010 21:59, Peter Neubauer wrote:
> Very cool,
> will be great to check it out, guess Tobias Ivarsson will be the first to
> try!
>
I added some tests [1] and a bit of documentation [2]. Whenever I get time,
I will implement index and traversals.
Regards.
[1] http://github.com/versae/
Thank you all, your ideas are great.
I guess to introduce some kind of pagination only make harder the work :-)
but it continues being interesting.
Best regards.
--
Javier de la Rosa
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mai
I did some benchmarking SSD vs "mechanical disk" using the batch
inserter injecting a dataset (social graph) that required ~10G to fit
in RAM on a 4G machine. Preliminary results indicate that there is no
difference.
The SSD used has about the same sequential write speed as the
mechanical disk and
Hi fellow graph-tastic people,
Allowing a transaction to span multiple requests was ruled out in the early
version of the REST API. It's a dangerous pattern that allows for inadvertent
(or even malicious) denial of service.
If we're going to build systems that sympathetic to the Web, then expo
REST "purists" prefer that each REST-ful invocation is atomic, but as
we all know, there are definitely cases where multiple "transactions"
need to be implemented.
The cleanest approach I've seen involved an explicit call to "create" a
transaction/unit of work, and some type of tr
Hi!
The guys who wrote the REST component are offline at the moment, so I'll
just chime in here for now.
You are right that the current REST API won't allow you to control
transactions: it wraps each request in a transaction.
There's basically two strategies, either you keep a transaction open
To further clarify, I run 2 tests. In the first test, my objects were
configured using spring + I had the @Transactional
annotation in the test method. In the second test, I configured the same
objects manually and also started and
commited the transaction before and after calling the test method
Hi,
I have not tried to reproduce this but just looking at the code I
think it is a bug so thanks for reporting it!
The "synchronization hook" that gathers the transaction data gets
registered in the call to GraphDatabaseService.beginTx() but when
using Spring (with that configuration) UserTransa
Strings and arrays are lazy load so the property data will not be read
until you request it.
-Johan
On Thu, May 20, 2010 at 1:58 PM, Mattias Ask wrote:
> Hi,
>
> I was just wondering one thing. Are properties on Nodes and Relationships
> lazy loaded? I mean, if I have an AccountNode which holds
On Wed, May 19, 2010 at 4:48 PM, Jawad Stouli wrote:
> Hi Johan and thanks for your answer.
>
> I think that I have figured out the major concepts behind PersistenceSource
> and I have a partially working prototype of Neo4j using Cassandra. As you
> stated it, I had to make some minor modification
Hi,
I was just wondering one thing. Are properties on Nodes and Relationships
lazy loaded? I mean, if I have an AccountNode which holds 5 large images and
I'm only interested in reading the name property of the account, when I read
the name will the images be read from disc?
Best,
Mattias
___
21 matches
Mail list logo
