[orientdb] Create distribution from maven repository
How do I create the distribution from the maven repository. when i build my project i need to pull the jars from maven and create the same structure as the distribution orientdb bin config databases lib orientdb-core-2.0.2.jar ... plugins www license.txt -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[orientdb] Custom Serialization of Embedded Documents
Hi everyone,
while playing around with OrientDB 2.0.4 I encountered the following
problem:
I have the following (schematic) classes
public class ClassA{
private String someData;
private ClassB embeddedClass;
}
public class ClassB implements Serializable{
private Integer someData;
private ClassC classToBeReferenced;
}
public class ClassC implements Serializable{
private Boolean someData;
}
Allthough ClassC should not be embedded but referenced in ClassB, ClassB
contains an actual instance of ClassC so that people can easily set an
instance of ClassC on ClassB (and not have to deal with OrientDB to get the
RID of the instance of ClassC).
The problem with this setup is that OrientDB embeds ClassC in ClassB when
an instance of ClassB is serialized. In order to avoid that I created a
custom serializer for ClassC:
public class ClassCSerializer implements OObjectSerializer {
}
My problem is now, that the solution with the custom implementation of
OObjectSerializer does not seem to work in verison 2.0.4 anymore, since I
cannot find an OObjectSerializerContext where the serializers can be added
to. I have orient-core, -client and -enterprise modules in version 2.0.4 on
my classpath.
Futhermore, I've tried to solve the problem by implementing
ODocumentSerializable with ClassB. But this is not an ideal solution
either, since the ODocument, which is created by the toDocument() method is
stored as an own entry in the database.
Can anybody help me out here?
Regards, Pascal
--
---
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, send an email
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[orientdb] Re: How to get records that are linked to each of given vertices
Ok here is an example:
CREATE DATABASE remote:localhost/testdb root root memory
CREATE CLASS Data EXTENDS V;
CREATE PROPERTY Data.id INTEGER;
CREATE CLASS Tag EXTENDS V;
CREATE PROPERTY Tag.name STRING;
CREATE CLASS hasTag EXTENDS E;
CREATE VERTEX Data SET id = 1;
CREATE VERTEX Data SET id = 2;
CREATE VERTEX Tag SET name = 'A';
CREATE VERTEX Tag SET name = 'B';
#Link to both A and B
CREATE EDGE hasTag FROM (SELECT FROM Data WHERE id = 1) TO (SELECT FROM Tag
WHERE name = 'A');
CREATE EDGE hasTag FROM (SELECT FROM Data WHERE id = 1) TO (SELECT FROM Tag
WHERE name = 'B');
#Link only to A
CREATE EDGE hasTag FROM (SELECT FROM Data WHERE id = 2) TO (SELECT FROM Tag
WHERE name = 'A');
#Get Data that is linked to both (Tag vertices having name) A and B, should
get Data with id = 1
SELECT FROM Data WHERE out('hasTag') CONTAINS (name = 'A') AND out('hasTag')
CONTAINS (name = 'B');
In my app Tag vertices (having name 'A' and 'B') are provided by the client
app and could be more than 2 Tags, that's why I'm trying to avoid the *CONTAINS
... AND CONTAINS* ... part, when building my query.
Thank you for your patience.
On Friday, 6 March 2015 05:36:04 UTC+1, Colin wrote:
>
> If A, B, C are all vertices and each represents a different type of class,
> then you could could create a different edge type for each one.
>
> Are A, B, C all unique types that derive from a common base?
>
> Maybe if you can give a more real-world example with the needed result, we
> can figure it out.
>
> Sorry, if I'm being dense. :-)
>
> -Colin
>
> On Thursday, March 5, 2015 at 4:05:44 PM UTC-6, Red-0ne wrote:
>>
>> Sorry for being misleading. A, B, C are vertices of themselves and
>> created through "CREATE VERTEX" command. I just tried to represent them by
>> their @rids in the above query.
>>
>> On Thursday, 5 March 2015 16:51:14 UTC+1, Colin wrote:
>>>
>>> I think I'm a little puzzled why/how A, B are @rids and vertices but
>>> not. :-)
>>>
>>> Are A, B, C always unique 'tags' as in properties of vertices that
>>> denote some kind of type? Or, are A, B, C types of vertices themselves?
>>>
>>>
>>> On Thursday, March 5, 2015 at 5:37:37 AM UTC-6, Red-0ne wrote:
Actually vertices A, B, C... are kind of *tags*, and Vi are *data*. My
use case is as simple as: "get data that matches *all* given tags".
On Tuesday, 3 March 2015 19:19:58 UTC+1, Colin wrote:
>
>
--
---
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, send an email
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [orientdb] Distributed OrientDB via Multi-host Docker
@toby thanks for the heads up about hazelcast variables, didn't know you could do that. And for sharing your setup. -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [orientdb] Distributed OrientDB via Multi-host Docker
@tobie thanks for the heads up about hazelcast variables, didn't know you could do that. And for sharing your setup -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[orientdb] Re: Record deadlock issue in 2.0.2
I am getting this error too. Any progress on this issue? My application is running OrientDB 2.0.4 Jing -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [orientdb] No index use when using sub query
Luca, So I'll try and give you a full test case early next week. But basically what I'm having trouble with is that its fine to put a index on the sub query and that will make that part faster. But if the sub query were to return 3000 rows the outer part of the query (where foo = "bar") will never use the index on 'foo', and becomes very slow +1second. I'll give you a full test case next week, however given an index on 'foo' and 'status' should that query be fast? Or am I misunderstanding something? Thanks, Jamie On 6 Mar 2015 16:38, "Luca Garulli" wrote: > Hi Jamie, > To speed up the query like: > >select from (select expand(in()) from User where status = 'active') > where foo = "bar" LIMIT 10 > You should have an index on User.status to avoid scanning all User. Can > you elaborate more the query that is slow? > > Lvc@ > > > On 5 March 2015 at 22:28, Jamie Blair wrote: > >> Luca, >> >> So I had problems with this approach if I needed to select on a larger >> collection rather that a single rid. So something along the lines of >> >>select from (select expand(in()) from User where status = 'active') >> where foo = "bar" LIMIT 10 >> >> I ran into problems I'm assuming I'm not quite think in the correct way. >> Also I know I could put a limit on in inner query also but that would mean >> that I could potentially end up with less than the required number of >> results. >> >> Hope that makes sense >> >> Thanks for the help, >> Jamie >> On 5 Mar 2015 19:48, "Luca Garulli" wrote: >> >>> Hi Jamie, >>> First, OrientDB supports direct loading by RID at O(1) cost. So this: >>> >>> SELECT FROM SomeVertex WHERE @rid in [#23:83354, #23:366, #23:99933, >>> #23:80708, #23:70291] >>> >>> Can be translated to: >>> >>> >>> *SELECT FROM [#23:83354, #23:366, #23:99933, #23:80708, #23:70291]* >>> That is MUCH faster. Don't put indexes on RIDs: RIDs are physical >>> positions and are the reason why OrientDB is so fast on traversing and >>> direct loading by RID. >>> >>> Then, in this query you're thinking relational: >>> >>> SELECT FROM SomeVertex WHERE @rid in (SELECT in FROM SomeEdge WHERE out >>> IN #27:819) >>> >>> Try this (it should take few ms): >>> >>> *SELECT expand(in()) FROM #27:819* >>> >>> If you want to filter by vertex's properties you can do: >>> >>> *SELECT FROM (* >>> >>> * SELECT expand(in()) FROM #27:819) WHERE age >= 18* >>> >>> Lvc@ >>> >>> >>> On 3 March 2015 at 11:42, Jamie Blair wrote: >>> Luigi, Thanks, but there is an extra part to our problem as soon as we want to put conditions on the Vertex we can't. So for our use case we have a lucene index on the Vertex:name, I've found the expand to not be very useful because it kind of backs me into a corner with adding conditions to my query. Is there a list of the current issues with the query optimizer anywhere? Also if anybody could give me an example of how I would also add a lucene condition to the above query that'd be greatly appreciated Thanks, Jamie On Tuesday, March 3, 2015 at 7:21:34 AM UTC, Luigi Dell'Aquila wrote: > > Hi Jamie, > > yes, the right thing to make it faster is this: > > select expand(inV()) FROM SomeEdge WHERE out IN #27:819 > > Currently there are no work arounds for that at parser level. > The problem is not tracked as a single issue because it's a wide > topic, and it's being addressed as a full development process, but if you > want you can create a specific issue for this > > Regards > > Luigi > > > 2015-03-02 18:11 GMT+01:00 Jamie Blair : > >> Luigi, >> >> Have you any idea how I would make this fast, or is there a work >> around for the present query optimizer? Also is there a ticket I can >> track >> in github for this? >> >> Thanks, >> Jamie >> >> On Monday, March 2, 2015 at 4:55:51 PM UTC, Luigi Dell'Aquila wrote: >>> >>> Hi Jamie, >>> >>> this is a known issue, we are working hard on the new query parser >>> and executor and one of the main goals of all this is query >>> optimization. >>> >>> Thanks >>> >>> Luigi >>> >>> >>> 2015-03-02 17:11 GMT+01:00 Jamie Blair : >>> The following query returns a set of `@rid` and completes in about `0.012sec` SELECT in FROM SomeEdge WHERE out IN #27:819 Now if I were to select from another Vertex using those `@rid`s in there literal form, this would take a very long time and I get a timeout (above 4seconds). I'm presuming its scanning over all the entries SELECT FROM SomeVertex WHERE @rid in [#23:83354, #23:366, #23:99933, #23:80708, #23:70291] Interestingly enough if I were to use a single `@rid` rather than a set it would be fast. So I'm assuming the query optimizer has the >>
Re: [orientdb] No index use when using sub query
Hi Jamie, To speed up the query like: select from (select expand(in()) from User where status = 'active') where foo = "bar" LIMIT 10 You should have an index on User.status to avoid scanning all User. Can you elaborate more the query that is slow? Lvc@ On 5 March 2015 at 22:28, Jamie Blair wrote: > Luca, > > So I had problems with this approach if I needed to select on a larger > collection rather that a single rid. So something along the lines of > >select from (select expand(in()) from User where status = 'active') > where foo = "bar" LIMIT 10 > > I ran into problems I'm assuming I'm not quite think in the correct way. > Also I know I could put a limit on in inner query also but that would mean > that I could potentially end up with less than the required number of > results. > > Hope that makes sense > > Thanks for the help, > Jamie > On 5 Mar 2015 19:48, "Luca Garulli" wrote: > >> Hi Jamie, >> First, OrientDB supports direct loading by RID at O(1) cost. So this: >> >> SELECT FROM SomeVertex WHERE @rid in [#23:83354, #23:366, #23:99933, >> #23:80708, #23:70291] >> >> Can be translated to: >> >> >> *SELECT FROM [#23:83354, #23:366, #23:99933, #23:80708, #23:70291]* >> That is MUCH faster. Don't put indexes on RIDs: RIDs are physical >> positions and are the reason why OrientDB is so fast on traversing and >> direct loading by RID. >> >> Then, in this query you're thinking relational: >> >> SELECT FROM SomeVertex WHERE @rid in (SELECT in FROM SomeEdge WHERE out >> IN #27:819) >> >> Try this (it should take few ms): >> >> *SELECT expand(in()) FROM #27:819* >> >> If you want to filter by vertex's properties you can do: >> >> *SELECT FROM (* >> >> * SELECT expand(in()) FROM #27:819) WHERE age >= 18* >> >> Lvc@ >> >> >> On 3 March 2015 at 11:42, Jamie Blair wrote: >> >>> Luigi, >>> >>> Thanks, but there is an extra part to our problem as soon as we want to >>> put conditions on the Vertex we can't. So for our use case we have a lucene >>> index on the Vertex:name, I've found the expand to not be very useful >>> because it kind of backs me into a corner with adding conditions to my >>> query. >>> >>> Is there a list of the current issues with the query optimizer anywhere? >>> Also if anybody could give me an example of how I would also add a lucene >>> condition to the above query that'd be greatly appreciated >>> >>> Thanks, >>> Jamie >>> >>> >>> On Tuesday, March 3, 2015 at 7:21:34 AM UTC, Luigi Dell'Aquila wrote: Hi Jamie, yes, the right thing to make it faster is this: select expand(inV()) FROM SomeEdge WHERE out IN #27:819 Currently there are no work arounds for that at parser level. The problem is not tracked as a single issue because it's a wide topic, and it's being addressed as a full development process, but if you want you can create a specific issue for this Regards Luigi 2015-03-02 18:11 GMT+01:00 Jamie Blair : > Luigi, > > Have you any idea how I would make this fast, or is there a work > around for the present query optimizer? Also is there a ticket I can track > in github for this? > > Thanks, > Jamie > > On Monday, March 2, 2015 at 4:55:51 PM UTC, Luigi Dell'Aquila wrote: >> >> Hi Jamie, >> >> this is a known issue, we are working hard on the new query parser >> and executor and one of the main goals of all this is query optimization. >> >> Thanks >> >> Luigi >> >> >> 2015-03-02 17:11 GMT+01:00 Jamie Blair : >> >>> The following query returns a set of `@rid` and completes in about ` >>> 0.012sec` >>> >>> SELECT in FROM SomeEdge WHERE out IN #27:819 >>> >>> Now if I were to select from another Vertex using those `@rid`s in >>> there literal form, this would take a very long time and I get a timeout >>> (above 4seconds). I'm presuming its scanning over all the entries >>> >>> SELECT FROM SomeVertex WHERE @rid in [#23:83354, #23:366, >>> #23:99933, #23:80708, #23:70291] >>> >>> Interestingly enough if I were to use a single `@rid` rather than a >>> set it would be fast. So I'm assuming the query optimizer has the scope >>> to >>> go a little further and also optimize multiple results >>> >>> SELECT FROM SomeVertex WHERE @rid in [#23:83354] >>> >>> But not to worry because I can make this faster by adding an index >>> to `SomeVertex.@rid` so now this is fast again >>> >>> CREATE INDEX foo on SomeVertex (@rid) unique >>> SELECT FROM SomeVertex WHERE @rid in [#23:83354,#23:366,#23:99933,# >>> 23:80708,#23:70291] >>> >>> But if I compose the 2 queries, I'd expect this to be fast, but it's >>> still slow and causes timeout (above 4 seconds) >>> >>> SELECT FROM SomeVertex WHERE @rid in (SELECT in FROM SomeEdge WHERE >>> out IN #27:819) >>> >>> I'm assuming I could write th
[orientdb] Configuring the Disk Cache Path
Hello Everyone. Is there a configuration setting for OrientDB to indicate the disk that should be used for disk caching? I know of the setting "-Dstorage.diskCache.bufferSize" to specify the size. However, I would like to specify a different disk where cache will be stored. Thank you. Amir. -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [orientdb] compound index seems to be ignored
Hi, I've attached the database export, including the defined index. And here's the query: SELECT @rid FROM User WHERE state="active" AND birthdayYear <= 1994 AND birthdayYear >= 1958 AND ageMin <= 59 AND ageMax >= 59 AND height <= 176 AND height >= 161 AND heightMin <= 188 AND heightMax >= 188 AND relationship IN ["free"] AND theirRelationship IN ["free", "doesntMatter" ] AND lookingFor IN ["relationship"] AND theirLookingFor IN ["relationship", "doesntMatter" ] AND @rid NOT IN [#12:0] Thank you for conducting this test. Best regards, Mate On Friday, March 6, 2015 at 9:37:19 AM UTC+1, Luigi Dell'Aquila wrote: > > Hi, > > A small sample database and the query you execute will be enough > > Thanks > > Luigi > > > 2015-03-05 21:18 GMT+01:00 Máté Gábri >: > >> Hi Luigi, >> >> sorry I'm new to this so please forgive my noob question. What should I >> provide so that you can test it? My code (nodejs) I'm using for testing, or >> some test data with the query and index I'm using? >> >> Best regards, >> Mate >> >> On Thursday, March 5, 2015 at 10:51:26 AM UTC+1, Luigi Dell'Aquila wrote: >>> >>> Hi Mate, >>> >>> there are no limitations in the number of properties that can be >>> indexed, so there must be a bug somewhere. >>> Could you provide a test case to reproduce it? >>> >>> Thanks >>> >>> Luigi >>> >>> >>> 2015-03-04 22:25 GMT+01:00 Máté Gábri : >>> Hi, I'm trying to get familiar with OrientDB's indexing to make some performance tests. I'm running a query on a class which uses 10+ conditions in the WHERE statement with range selections, constants and IN conditions. I've created the compound index in the same order as the fields appear in the WHERE statement but it seems like the index is ignored. The EXPLAIN command shows that the index is used, but the scanned documents number is the same as the number of documents in the class. After some experimentation I came to the conclusion that with 2 conditions the index is "working", so just part of the class is scanned, but after adding the third condition the whole class is scanned. I'm just not sure wether this is normal behaviour or not. Am I missing something? Best regards, Mate -- --- 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, send an email to orient-databa...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. >>> >>> -- >> >> --- >> 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, send an >> email to orient-databa...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. test.json.gz Description: Binary data
[orientdb] Re: Adding edges with properties after using Document API
Well, with either approach you're actually using the Graph API once you start using the OrientGraph object. A Vertex (OrientVertex) is built on top of a document, and its ODocument can be obtained by calling vertex.getRecord(). But an ODocument is not a Vertex. By working with OrientVertex objects, you essentially get the best of both worlds. If you don't need the automatic management of links, then ODocument is just fine. -Colin Orient Technologies The Company behind OrientDB On Friday, March 6, 2015 at 5:04:43 AM UTC-6, Christian C wrote: > > Actually the better approach for me is to stick with the document api and > do like so: > > ODatabaseDocumentTx db = pool.acquire(); > OrientGraph g = new OrientGraph(db); > > > Out of interest is the a way to cast ODocument to Vertex and vice versa? > > > PS Would be nice if you could provide a one liner in the wiki for the > Document API and for the Graph API how to get the otherone. This my help new > commers a lot. > > -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[orientdb] SelectionStrategy
Hi, I have some questions regarding cluster selection. I followed instructions from this documentation (http://www.orientechnologies.com/docs/last/orientdb.wiki/Cluster-Selection.html) but I think something is not ok. As I debugging the server I saw that strategy selection is done server side not on client side. Is there any way to specify this from client side? So as I understand the custom cluster strategy implementation must be added to server instance classpath not to the client classpath. Thank you! -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[orientdb] Re: Adding edges with properties after using Document API
Actually the better approach for me is to stick with the document api and do like so: ODatabaseDocumentTx db = pool.acquire(); OrientGraph g = new OrientGraph(db); Out of interest is the a way to cast ODocument to Vertex and vice versa? PS Would be nice if you could provide a one liner in the wiki for the Document API and for the Graph API how to get the otherone. This my help new commers a lot. -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [orientdb] Distributed OrientDB via Multi-host Docker
Awesome! I'm happy to see so many options now. Back when I had this
problem, couldn't find much of a solution. Glad that users will now have
multiple options where to start from when using ODB with Docker.
@Tobie thank you for your image. Haven't tried yet, but looks solid.
On Thu, Mar 5, 2015 at 7:42 PM, Simon Gemmell
wrote:
> Here is my set up: orientdb running in a docker container on an AWS server
> in Frankfurt, and a similar container on AWS in Sydney. IPSEC tunneling
> between them. My docker file looks like this:
>
> FROM dockerfile/java:oracle-java8
>
> MAINTAINER Simon Gemmell
>
> # Update the default application repository sources list
> RUN apt-get update
>
> # Install supervisord
> RUN apt-get -y install supervisor
> RUN mkdir -p /var/log/supervisor
>
> # Install orientdb
> ENV ORIENT_VERSION orientdb-community-2.0.3
> ENV ORIENT_TAR ${ORIENT_VERSION}.tar.gz
> ENV ORIENT_URL
> http://www.orientechnologies.com/download.php?file=${ORIENT_TAR}
> ENV ROOT /opt
>
> RUN cd ${ROOT} \
> && curl -o ${ORIENT_TAR} ${ORIENT_URL} \
> && tar -xzf ${ORIENT_TAR} \
> && ln -s ${ROOT}/${ORIENT_VERSION} ${ROOT}/orientdb \
> && ln -s ${ROOT}/orientdb/bin/*.sh /usr/local/bin/ \
> && mkdir /usr/local/log
>
> # cleanup
> RUN apt-get -y -qq --force-yes clean \
> && rm -rf /opt/downloads/linux /var/lib/apt/lists/* /tmp/* /var/tmp/*
>
> # use supervisord to start orientdb
> ADD supervisord.conf /etc/supervisor/conf.d/supervisord.conf
>
> #EXPOSE 2424
> EXPOSE 2480
> EXPOSE 5701
>
> # Set the user to run OrientDB daemon
> USER root
>
> # Default command when starting the container
> CMD ["/usr/bin/supervisord", "-c",
> "/etc/supervisor/conf.d/supervisord.conf"]
>
>
> I don't expose 2424 as it is "linked" to another container.
>
> Then I run it like this:
> #!/bin/bash
> sudo docker run --name orientdb -d -v
> `pwd`/orientdb/config:/opt/orientdb/config -v
> /mnt/EBS/databases:/opt/orientdb/databases -v
> /mnt/EBS/backup:/opt/orientdb/backup -v `pwd`/orientdb/log:/var/log -p
> 2424:2424 -p 2480:2480 -p 5701:5701 tkbt/orientdb
> cd orientdb
> ./updateip.sh
> cd ..
>
>
> updateip.sh does this:
> #!/bin/bash
> IP=`sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}'
> orientdb`
> sed -i 's/.*/ name="hazelcast.local.localAddress">'$IP'<\/property>/' config/hazelcast.xml
>
>
> My supervisord:
> [supervisord]
> nodaemon=true
>
> [program:orientdb]
> directory=/opt/orientdb/bin/
> command=server.sh -Ddistributed=true -Xmx1024m
> autostart=true
> autorestart=true
> stderr_logfile=/var/log/orientdb.err.log
> stdout_logfile=/var/log/orientdb.out.log
> ; startsecs 5 delays starting orient by 5 secs, which will allow any
> external scripts to update IPs etc
> startsecs = 5
> stopwaitsecs = 120
> ; make sure we send the signals to any process started by the top scripts
> stopasgroup=true
>
>
> My hazelcastconfig:
>
>
>false
>false
>false
>0
>jdk
> name="hazelcast.local.localAddress">172.17.0.22
> name="hazelcast.socket.server.bind.any">false
>false
>
>
>
> 10.0.1.96
>
> 5701
>
>
>0
>
>
>
>
> 224.2.2.3
> 54327
>
>
>
> 172.31.6.12
>
>
>
>
> 16
>
> ...
>
>
> On Thursday, March 5, 2015 at 6:32:36 AM UTC+11, Tobie Morgan Hitchcock
> wrote:
>>
>> Hi Luca,
>>
>> Docker differences
>>
>> 1. Using `centos:7` not `debian`
>> 2. Using `java-1.7.0-openjdk-headless` instead of `java-1.7.0-openjdk`
>> 3. The OrientDB install tar file (https://abcum-deploy.s3.
>> amazonaws.com/orient/orientdb-community-2.0.4.tar.gz) is an exact copy
>> of the one available at http://www.orientechnologies.com/download/
>> except that it has had the demo database removed to make it smaller.
>> 4. The OrientDB configs are included in the docker image in the /conf/
>> folder, and do not need to be included on a shared volume.
>> 5. The OrientDB config and startup script has been simplified slightly so
>> that it runs in the foreground on CoreOS in a distributed setup.
>> 6. Running the docker image will launch a 'ready to go' distributed
>> OrientDB instance using either TCP or AWS node discovery.
>> 7. The OrientDB instance is launched in the foreground (not as a daemon)
>> so that it can be controlled by Fleet on CoreOS
>> 8. Using Hazelcast variables (http://blog.hazelcast.com/
>> 2013/08/14/xml-variables/) for putting the docker environment variables
>> into the hazelcast.xml file.
>>
>> If running OrientDB on a CoreOS cluster in Amazon EC2/VPC you should be
>> able to launch any number of OrientDB instances which connect with each
>> other using the Fleetctl service file, which is include
[orientdb] Analytics data
Relative newbie Currently testing/building Analytical app with OrientDB. Really like it al lot! One thing that i cant figure out is the best way to import (historical) google analytics data on a daily base. Is the use of indexes the way to go? Or do i create Vertex for every adwords campaign per day and add an edge with date property from campaginID? Order <-> E <-> AdcampaingId -> E (date) -> campaingdata of day X Would create massive amount of documents... does that impact performance? Cant find other users/documentation besides couple of links that point to indexes. A point in the right direction would help me a lot! Thx Regards, Coen -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [orientdb] compound index seems to be ignored
Hi, A small sample database and the query you execute will be enough Thanks Luigi 2015-03-05 21:18 GMT+01:00 Máté Gábri : > Hi Luigi, > > sorry I'm new to this so please forgive my noob question. What should I > provide so that you can test it? My code (nodejs) I'm using for testing, or > some test data with the query and index I'm using? > > Best regards, > Mate > > On Thursday, March 5, 2015 at 10:51:26 AM UTC+1, Luigi Dell'Aquila wrote: >> >> Hi Mate, >> >> there are no limitations in the number of properties that can be indexed, >> so there must be a bug somewhere. >> Could you provide a test case to reproduce it? >> >> Thanks >> >> Luigi >> >> >> 2015-03-04 22:25 GMT+01:00 Máté Gábri : >> >>> Hi, >>> >>> I'm trying to get familiar with OrientDB's indexing to make some >>> performance tests. I'm running a query on a class which uses 10+ conditions >>> in the WHERE statement with range selections, constants and IN conditions. >>> I've created the compound index in the same order as the fields appear in >>> the WHERE statement but it seems like the index is ignored. The EXPLAIN >>> command shows that the index is used, but the scanned documents number is >>> the same as the number of documents in the class. After some >>> experimentation I came to the conclusion that with 2 conditions the index >>> is "working", so just part of the class is scanned, but after adding the >>> third condition the whole class is scanned. I'm just not sure wether this >>> is normal behaviour or not. Am I missing something? >>> >>> Best regards, >>> Mate >>> >>> -- >>> >>> --- >>> 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, send >>> an email to orient-databa...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > > --- > 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, send an > email to orient-database+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- 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, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
