For your first solution, I don't see the point in using the time series
structure at all. You're just using an indexed timestamp field and next
pointers to traverse the range. The solution I outlined doesn't need any
index or next links. Finding the first date is very fast and, no matter how
bi
What I've done is this:
1. Find the vertex for the start date (or closest one after it).
2. Increment your finest time unit (in my case seconds, but it may be days)
until you find a match in the map.
3. When you get past the maximum value for that unit (59 in the case of
seconds), move up to the
s working on a collection (ignoring that also maps
> are iterable)
>
> Luigi
>
>
> 2015-09-16 17:10 GMT+02:00 Curtis Stanford >:
>
>> Hi Luigi. Thanks for your response. I don't understand how a Map could
>> behave like an Iterable. I need to look up values
Hi Luigi. Thanks for your response. I don't understand how a Map could
behave like an Iterable. I need to look up values on the map with a key,
which you can't do with an Iterable. I wonder what the initial reason was
for that change. Why not just return the map instead of explicitly changing
i
> abstraction over some Key-Value DB and so on...
> I quite like that concept so far, but there aren't many alternatives so I
> am not making any conclusions.
>
> Dne pondělí 14. září 2015 23:46:43 UTC+2 Curtis Stanford napsal(a):
>>
>> Good points. I would like to
Good points. I would like to be able to do something like:
Map map = vertex.getProperty("map"); // returns a map,
not an iterable
map.remove("a");
map.put("b", new ODocument());
// change is saved when transaction is committed.
Also, since every vertex has an ID, just like an ODocument, I don't
Thank you for the great response. I will try the save() approach. It would
probably perform better than setting the map again. I was hoping there was
a way to do this using just the graph API but this will do for now.
A small issue with your code: the Vertex class doesn't have a getRecord()
met
maps which reference it.
> Data integrity is maintaned only on edges, because unlike LINKs, both
> connected records (vertexes) knows about the link.
>
> Dne neděle 13. září 2015 22:18:21 UTC+2 Curtis Stanford napsal(a):
>>
>> I'm thinking of use large LINK MAPs in a graph d
I'm thinking of use large LINK MAPs in a graph database using the Java API.
I'm not sure what the most efficient way is to get and update/remove
entries in the map. I don't want to have to persist the entire map each
time, just the entries that have changed.
Any help appreciated.
Curtis
--
This is still causing me grief. Isn't there any way to get a LINK MAP (i.e.
Map) from a vertex? The problem with using
vertex.getRecord().field("propName") is that any changes to the map are not
persisted to the vertex. I have to do a vertex.setProperty("propName", map)
to persist it but I'm no
I have a classic time-series case using maps to store
year/month/day/hour/minute/second vertices. These maps are all LINKMAPs
where the links point to other vertices. They are not embedded, nor do I
want them to be embedded. Now, using 2.1, getting these link maps from a
vertex results in:
jav
Version 2.0.8. Any way to fix this?
com.orientechnologies.orient.core.exception.OStorageException: File with id
66 does not exist.
at
com.orientechnologies.orient.core.index.hashindex.local.cache.OWOWCache.openFile(OWOWCache.java:322)
at
com.orientechnologies.orient.core.index.hashindex.local.c
I'm getting these OCM errors a lot too in 2.0.2. Only one thread runs at a
time in a servlet environment. Sometimes, I get old data from a cache and
get an OCM. Everything works if I invalidate the cache everytime.
I get connections using a single instance of OrientGraphFactory:
OrientGraph g =
Ooops, never did test this. However, it is still a problem in 2.0-rc2.
On Friday, July 18, 2014 at 4:32:12 AM UTC-6, Andrey Lomakin wrote:
>
> Hi,
> It is fixed in 1.7.7-SNAPSHOT.
> Could you try ?
>
>
> On Fri, Jun 27, 2014 at 12:17 AM, Curtis Stanford <
> cur...@st
1, #1:3]
> key: Roberto, value: [#1:2]
> key: Raffaella, value: [#1:4]
> You can see how an index of 3 records can exist.
>
> Cheers,
>Riccardo
>
> 2014-11-19 22:19 GMT+01:00 Curtis Stanford >:
>
>> I have a vertex class that has 58,383 records in it. I also
I can see from the code that it only does the first. I'd like to submit a
request that edges be made to all matching results.
On Wednesday, November 19, 2014 2:29:10 PM UTC-7, Curtis Stanford wrote:
>
> I have a question about creating edges with ETL. If the index named in the
I have a question about creating edges with ETL. If the index named in the
"lookup" property of the edge transformer returns more than 1 result, will
edges be creating to all of the resulting vertices or just the first one?
I'm only seeing one edge created even though the lookup should return mo
I have a vertex class that has 58,383 records in it. I also have a
NOTUNIQUE index on one of the fields. A select count(*) on the index itself
results also in 58,383. However, typing "indexes" in the console shows that
it only has 43,342 records. Why is it different?
I tried rebuilding the inde
Yah, sorry about that. Must of been using M2. Thanks!
On Tuesday, November 18, 2014 3:05:16 PM UTC-7, Lvc@ wrote:
>
> Hi Curtis,
> I think you're using old libraries to open the database created with
> OrientDB 2.0-M3. Could you double check it?
>
> Lvc@
>
>
> O
I made this test a littler simpler by just loading one table of 519
records. Here is my etl json file. It's just loading one table from a
postgresql database into orientdb. Still get the same error. I can actually
connect to the database using the console but not with the Java API.
{
"
I've used ETL in 2.0-M3 to load a few million records in a brand new plocal
database. When I try to open the database using the Java API, I get the
following exceptions. I've tried it a couple of times. Any ideas what's
wrong here?
java.lang.reflect.InvocationTargetException
at sun.reflect.Nati
Looking at it more, 1.7.8 is also increasing the version numbers but I'm
not getting all of the concurrent modification exceptions that I'm getting
in 2.0M1. Perhaps 2.0 is checking them differently?
Not sure what's going on.
On Friday, September 19, 2014 11:22:38 AM UTC-6,
This behaviour seems to be different between 1.7.8 and 2.0M1. If you take
two vertices, V1 and V2 and create and edge E between them, V1 and V2 now
show as updated and the version number of both increases. This make a lot
of code I had before break because it didn't happen in 1.7.8. I don't thin
I'm not sure this can be defined a bug! is a design choice ;)
>
> bye
> Emanuel
>
> On 09/08/2014 11:11 PM, Curtis Stanford wrote:
>
> Probably has something to do with these lines in OStorageAbstract.java:
>
> public OStorageAbstract(final String name, fi
Probably has something to do with these lines in OStorageAbstract.java:
public OStorageAbstract(final String name, final String iURL, final String
mode, final int timeout,
final OCacheLevelTwoLocator cacheLocator) {
if (OStringSerializerHelper.contains(name, '/'))
this.name = name.subst
I think I've tracked down the problem. I've been using the following
directory structure for my databases:
/Users/me/projects//db
where the is different for each database. Orientdb seems to take the
last part of the path (db) as the unique identifier for the database. So,
even though I have 4
t;url",oG.
> getRawGraph().getURL()).vertices();
> Assert.assertTrue(vertices.iterator().hasNext());
> Vertex next = vertices.iterator().next();
> System.out.format("vertex : %s url:%s%n", next, next.
> getProperty("url"));
&
OK, perhaps I should first ask, has anyone been able to access multiple
plocal instances from one JVM?
On Friday, September 5, 2014 5:23:07 PM UTC-6, Curtis Stanford wrote:
>
> I'm trying to run one JVM instance with 4 embedded graph databases in
> different directories. Is th
I'm trying to run one JVM instance with 4 embedded graph databases in
different directories. Is this possible in 1.7.8? I've tried creating the
OrientGraph instance directly and using the OrientGraphFactory but can't
get it to work. I've tried using the thread modes of MANUAL and
ALWAYS_AUTOSET
How does one do this now? There is no ODatabaseThreadLocal class in 1.7.8.
On Thursday, June 26, 2014 5:35:44 AM UTC-6, M B wrote:
>
> We've done this quite heavily where we have 2 databases and access is
> spread across many threads and are constantly switching between access of
> either databa
Sorry for the delay. Will try to test this week.
On Friday, July 18, 2014 4:32:12 AM UTC-6, Andrey Lomakin wrote:
>
> Hi,
> It is fixed in 1.7.7-SNAPSHOT.
> Could you try ?
>
>
> On Fri, Jun 27, 2014 at 12:17 AM, Curtis Stanford <
> cur...@stanfordcomputing.com > wro
This was not fixed in 1.7.4
On Thursday, June 19, 2014 8:50:59 AM UTC-6, Andrey Lomakin wrote:
>
> Hi,
> You can retrieve documents using following code getRecord.field("prop")
>
> I also I will fix it in 1.7.4
>
>
>
> On Wed, Jun 18, 201
OK, thank you Andrey.
On Thursday, June 19, 2014 8:50:59 AM UTC-6, Andrey Lomakin wrote:
>
> Hi,
> You can retrieve documents using following code getRecord.field("prop")
>
> I also I will fix it in 1.7.4
>
>
>
> On Wed, Jun 18, 2014 at 7:28 PM, Curtis Stan
When using 1.7.2, I had an ODocument with a bunch of embedded ODocument's
that I retrieved using getProperty("prop") and casting to a java.util.List.
Now, in 1.7.3, the cast fails. It is now an OrientElementIterator. However,
I can't retrieve the elements in the iterator because I get the except
Seems to have disappeared from any repository. Makes it difficult to use
orientdb-graphdb-1.7-rc2 with maven/gradle, etc.
Curtis
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it
ts API you can use:
> vertexClass.createEdgeProperty(Direction.OUT,
> "EdgeClass").setOrdered(true);
>
> Take a look on example:
> https://gist.github.com/enisher/11363396
>
>
>
> Best regards,
> Artem Orobets
>
> *Orient Technologies the Company behind OrientDB*
>
>
>
As of version 1.7, when adding edges of the same class to a vertex (in
graph database) is there any order guaranteed (i.e. from earliest to latest
edges)?
I was hoping I could assume that edges added later are after the earlier
ones when traversing the edges (using Java API)
Curtis
--
---
So I guess future releases of 1.7 will not do this?
On Wednesday, April 23, 2014 10:16:56 AM UTC-6, Lvc@ wrote:
>
> Because we released 1.7rc2 before TinkerPop released Blueprints 2.5.0.
>
> Lvc@
>
>
>
> On 23 April 2014 17:59, Curtis Stanford
>
> > wrote:
>
Hi Luca, just wondering why, when I include dependencies for
orientdb-1.7-rc2, it still pulls in blueprints-2.5.0-SNAPSHOT
On Tuesday, April 15, 2014 10:59:13 AM UTC-6, Lvc@ wrote:
>
> Hi,
> for all the guys are using OrientDB with Blueprints/Gremlin/Rexster you
> should to know that starting fr
I don't see any way to query for a certain vertex class using the
blueprints API.
I can cast the GraphQuery object to OrientGraphQuery and use the
labels(...) method to do it but I don't see any pure blueprints way to do
it.
Am I missing something?
Curtis
--
---
You received this message
Duh, nevermind. It uses all the other blueprints stuff I guess.
On Thursday, January 30, 2014 1:37:45 PM UTC-7, Curtis Stanford wrote:
>
> The orientdb-graphdb 1.6.4 pom still has dependencies to tinkerpop
> artifacts. I thought these were all embedded now? It's causing reall
The orientdb-graphdb 1.6.4 pom still has dependencies to tinkerpop
artifacts. I thought these were all embedded now? It's causing really
confusing dependency issues in my project.
Curtis
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To un
YAY! Nice to see the integrated Blueprints. Thanks Luca!
On Wednesday, January 15, 2014 4:28:09 PM UTC-7, Lvc@ wrote:
>
> Hi all,
> Orient Technologies has just released OrientDB 1.6.4 as hot-fix + the
> integration with Blueprints.
>
> Yes, starting from 1.6.4 the Blueprints implementation has
43 matches
Mail list logo
