[orientdb] Re: Best practice to map OrientDB ORecordId onto RestFull friendly ID representation

Also answered on SE. Scott -- --- 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

[orientdb] Re: Best practice to map OrientDB ORecordId onto RestFull friendly ID representation

We're looking into using HashID. http://hashids.org/ There are some minor concerns we have still, but theoretically, HashID should get you a hashed Rid, which is also convertible, so it won't take up more storage space (like with a UUID). It will just take a small bit of CPU time. Please

[orientdb] Re: from the orientdb console.sh ,I could't get the right server-configuration

thank you , I get it 在 2016年5月24日星期二 UTC+8下午5:30:28，SavioL写道： > > I answered you on StackOverflow ( > http://stackoverflow.com/questions/37407953/from-the-orientdb-console-sh-i-couldt-get-the-right-server-configuration/37409508#37409508 > ) > > Il giorno martedì 24 maggio 2016 10:19:29 UTC+2,

[orientdb] Best practice to map OrientDB ORecordId onto RestFull friendly ID representation

Hi OrientDB experts, We are looking into OrientDB as our persistency solution behind a restful web service, because a GraphDB would be a perfect match for our use case. One of the things we have noticed is that entities (both Vertex and Edges) are uniquely identified by a ORecordId, containing

Re: [orientdb] Re: Server-side function: unable to read new/updated data from within same transaction

You're right: if you deploy your logic in the server, your function will be in the TX scope. I've just created your function on an empty database and works: [ { "@type": "d", "@rid": "#19:0", "@version": 1, "@class": "UserProfile", "name": "test10-5"

Re: [orientdb] Re: Server-side function: unable to read new/updated data from within same transaction

Actually, unless I am mistaken you are saving then querying within the *same* server-side function. In this instance, it *should* work I think. Will let the OrientDB guys comment. On Monday, May 23, 2016 at 5:11:03 PM UTC+1, Jean-Sebastien Lemay wrote: > > I now realize that what I'm looking

Re: [orientdb] Edges in 2.2 GA

yes, in traversal performance you will definitely have some advantages with lightweight edges Thanks Luigi 2016-05-24 17:04 GMT+02:00 Eric Lenington : > OK. That makes sense. The only reason I'm inclined to use Lightweight > edges is for performance reasons (is that not still a

Re: [orientdb] Edges in 2.2 GA

OK. That makes sense. The only reason I'm inclined to use Lightweight edges is for performance reasons (is that not still a factor?). I don't see using "promotable" edges (that start off Lightweight and may become Regular at some point), but assuming there is still a performance advantage, I can

Re: [orientdb] Edges in 2.2 GA

Hi Eric, There are no big penalties, the only real problem is that edge schema is not validated because lightweight edges are not instantiated as ODocuments, so the validation does not run (eg. if you define a mandatory property on the edge class, it won't be validated with lightweight). For the

Re: [orientdb] Edges in 2.2 GA

Thanks for the quick response and the clarification. So really, there isn't any penalty for running with Lightweight Edges enabled, since they will automatically be created as Regular edges when they have properties (as long as you're aware of this distinction)? Also, when running with

Re: [orientdb] Edges in 2.2 GA

Hi, By default all the edges are created as *regular* edges. This default can be changed from Studio or with an SQL statement http://orientdb.com/docs/last/Lightweight-Edges.html In this case, an edge is created as a lightweight edge only if it has no properties. When you add a property to a

[orientdb] Edges in 2.2 GA

Since this has changed since a lot of the documentation was written, I want to get a definitive answer on how edges are handled in 2.2. Is it true that any edge created will be a Lightweight Edge if no properties are defined for it? Does this also apply to edge classes that derive from E or

Re: [orientdb] OrientDb 2.1.15 java.net.SocketException: Too many open files when 9+ Databases are created

Roger. So ODB will go about its business and ignore the useless PARALLEL, if the minimum clusters is set to 1. That is good! Thanks! Scott -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving

Re: [orientdb] Index Engine error at startup for OrientDB 2.2.0

Hi, I have created issue https://github.com/orientechnologies/orientdb/issues/6202 , I will provide patch for you inside of this issue to get more details about this problem. On Mon, May 23, 2016 at 8:51 PM Tai Hu wrote: > I just upgraded to OrientDB 2.2.0 GA release from

[orientdb] Re: from the orientdb console.sh ,I could't get the right server-configuration

I answered you on StackOverflow (http://stackoverflow.com/questions/37407953/from-the-orientdb-console-sh-i-couldt-get-the-right-server-configuration/37409508#37409508) Il giorno martedì 24 maggio 2016 10:19:29 UTC+2, GANG NG ha scritto: > > I set the db.pool.min and db.pool.max in the

[orientdb] from the orientdb console.sh ,I could't get the right server-configuration

I set the db.pool.min and db.pool.max in the orientdb-server-config.xml , ,but I can't get db.pool.min =10 and db.pool.max =30 from OGlobalConfiguration.dumpConfiguration(System.out) this is my OGlobalConfiguration.dumpConfiguration(System.out) result: