Thanks Andreas for the input,
I guess if Stuart McCulloch is doing it in PaxConstruct, we can stop
arguing :) So, no problems from the OSGi side for root-package-APIs :)
Cheers,
/peter neubauer
COO and Sales, Neo Technology
GTalk: neubauer.peter
Skype peter.neubauer
Phone +46
The internal query engine (which is currently under planning) will be able to
access only those fields that require evaluation. It's probably wise to expose
such interface in the public API through dynamic proxies, but I consider it a
long term feature.
Anyway, thanks for sharing your experience
Honestly, I've handled package naming both ways and have yet to settle
on a preferred scheme. I like the explicitness of a *.api making it
obvious where to find the public interface for bundle services. But,
if a bundle is more of a library, then I expect the top-level package
to have what I want.
+1
On Jan 6, 2010, at 4:52 PM, Tobias Ivarsson wrote:
> On Wed, Jan 6, 2010 at 10:36 PM, Mattias Persson
> wrote:
>
>> 2010/1/6 Rick Bullotta :
>>> It's a relatively minor thing to fix in our code. I would suggest
>>> reconsidering the "retro" façade, however - it really doesn't buy you
>> much
On Wed, Jan 6, 2010 at 10:36 PM, Mattias Persson
wrote:
> 2010/1/6 Rick Bullotta :
> > It's a relatively minor thing to fix in our code. I would suggest
> > reconsidering the "retro" façade, however - it really doesn't buy you
> much
> > and requires resources to keep it up-to-date, fattens up th
2010/1/6 Rick Bullotta :
> It's a relatively minor thing to fix in our code. I would suggest
> reconsidering the "retro" façade, however - it really doesn't buy you much
> and requires resources to keep it up-to-date, fattens up the JAR a bit, and
> so on. If we're going to all move to the new ve
Hi there,
from an OSGi perspective, everything between bundles is handled on
package level. From that perspective, separation of api and impl (and
others) is better separated via org.neo4j.api and org.neo4j.impl etc.
Otherwise, e.g. the org.neo4j.* would be exported from the bundle
containing the a
Sounds good, minor changes for us, I'd probably think twice about the
retro facade to, pre 1.0 you shouldn't be expected to worry about
backward compatability should you?
D
On 6 Jan 2010, at 20:59, Craig Taverner wrote:
> +1
>
> On Wed, Jan 6, 2010 at 9:57 PM, Rick Bullotta <
> rick.bullo...@b
+1
On Wed, Jan 6, 2010 at 9:57 PM, Rick Bullotta <
rick.bullo...@burningskysoftware.com> wrote:
> It's a relatively minor thing to fix in our code. I would suggest
> reconsidering the "retro" façade, however - it really doesn't buy you much
> and requires resources to keep it up-to-date, fattens
It's a relatively minor thing to fix in our code. I would suggest
reconsidering the "retro" façade, however - it really doesn't buy you much
and requires resources to keep it up-to-date, fattens up the JAR a bit, and
so on. If we're going to all move to the new version, it's best to use the
new p
On Wed, Jan 6, 2010 at 21:48, Craig Taverner wrote:
> 1. Will a restructuring like this cause problems for your projects?
> Yes, but minor. Should be a simple search and replace to upgrade.
And if you need backwards compatibility then you can just go through
the 'retro' component.
>
> 2. Do you
1. Will a restructuring like this cause problems for your projects?
Yes, but minor. Should be a simple search and replace to upgrade.
2. Do you think this change will result in a positive overall effect for
Neo4j?
Perhaps. You're pushing for more use of the terms 'graph' and 'graph
database', and
Hi all!
For our upcoming final 1.0 release we are thinking about restructuring the
components and package names to make them at least closer to something we
would want to live with for a considerable future. The main affected
component at this point is the Neo4j kernel, even if other components wo
Hi,
The implementation was not thread safe and the last commit to the
underlying implementation was years ago. There was no time to fix it
before the 1.0 release so we decided to remove it. After 1.0 has been
released we may add it again (if the threading issue can be resolved).
Regards
-Johan
No, it is not a feature yet. If you think it'll be of use, log it at
http://code.google.com/p/jo4neo/issues/list
Taylor
- Original Message
From: Subhash Chandran
To: Neo user discussions
Sent: Wed, January 6, 2010 9:29:16 AM
Subject: Re: [Neo] deprecated neo indexer: experiences
correct me if I'm wrong but the way I see it is that Traverser is
itself iterable so you can do:
for (Node node: traverser) {
}
While you could assume that the nodes includes are determined by the
ReturnableEvaluator this give you an extra chance to further pick the
nodes to manipulate before stu
Is it possible to access neo4j's Lucene full-text indexing also in jo4neo?
Subhash.
On Wed, Jan 6, 2010 at 8:23 PM, Taylor Cowan wrote:
> After noticing that the neo indexer implementation was deprecated, I
> migrated my code towards the Lucene version. The neo indexer was noticeably
> faster
After noticing that the neo indexer implementation was deprecated, I migrated
my code towards the Lucene version. The neo indexer was noticeably faster and
while the errors (mostly related to transactions) Lucene exposed were my fault,
the neo version was more tolerant so to speak.
In general
On 6 Jan 2010, at 14:33, Emil Eifrem wrote:
> On Wed, Jan 6, 2010 at 15:29, Tim Langley wrote:
>> When I try to access the collection (getAllNodes)
>> for example to see how large the result set is then the traverser is
>> automatically dumped to the last node (or reset)
>
> That's the expected
On Wed, Jan 6, 2010 at 15:29, Tim Langley wrote:
> When I try to access the collection (getAllNodes)
> for example to see how large the result set is then the traverser is
> automatically dumped to the last node (or reset)
That's the expected result. getAllNodes() is a convenient method that
bas
Hello everyone
Quick question about the Interface Traverser
The specs describe an iterator and a collection
Are these two methods exclusive
When I try to access the collection (getAllNodes)
for example to see how large the result set is then the traverser is
automatically dumped to the last no
21 matches
Mail list logo
