Hi, Indexing of embedded properties is not supported yet, even if there is this PR that does it:
https://github.com/orientechnologies/orientdb/pull/7093 We didn't merge in the official branch because some test cases are still missing, but you could use it. In this case, please comment the PR to see how is going. Thanks. Best Regards, Luca Garulli Founder & CEO OrientDB LTD <http://orientdb.com/> On 10 February 2017 at 16:15, Oleksandr Gubchenko <user.work...@gmail.com> wrote: > Choose from one of the embedded types: > http://orientdb.com/docs/last/Types.html > > Il giorno giovedì 9 febbraio 2017 19:39:49 UTC+1, André Toscano ha scritto: >> >> Hi everyone >> We are using OrientDB like mongodb for some properties and it is working >> very well but we need to index some keys of the document (considering >> JSON). >> Please, what is the type of a property that stores a json object with >> many levels nested? >> Thanks in advance >> Best regards >> André >> >> On 6 Jan 2017 06:24, <orient-...@googlegroups.com> wrote: >> >> orient-database@googlegroups.com >> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/orient-database/topics> >> Google >> Groups >> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> >> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> >> Topic digest >> View all topics >> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/orient-database/topics> >> >> - Proper way to generate and insert data into OrientDB >> >> <#m_8605816414272133637_CAPrw5MEiW4xEetA8hd-qYQzfgnfdWR0q61D4=-KHmaaMQ4yfyw@mail.gmail.com_m_4313801924897894530_group_thread_0> >> - 2 Updates >> - Kotlin >> >> <#m_8605816414272133637_CAPrw5MEiW4xEetA8hd-qYQzfgnfdWR0q61D4=-KHmaaMQ4yfyw@mail.gmail.com_m_4313801924897894530_group_thread_1> >> - 1 Update >> - Reached maximum number of concurrent connections >> >> <#m_8605816414272133637_CAPrw5MEiW4xEetA8hd-qYQzfgnfdWR0q61D4=-KHmaaMQ4yfyw@mail.gmail.com_m_4313801924897894530_group_thread_2> >> - 1 Update >> >> Proper way to generate and insert data into OrientDB >> <http://groups.google.com/group/orient-database/t/847440ecf0235c40?utm_source=digest&utm_medium=email> >> Cyprien Gottstein <gottstei...@gmail.com>: Jan 05 06:44AM -0800 >> >> Hi, >> >> The scripts are in java, those are not batches, and we didn't wanted to >> post it online to be perfectly honest. >> >> But. >> >> Great news, problem solved ! >> >> I remembered something crucial, it's mainly me who is working on the >> subject and at first i wanted to run the OrientDB server on my own local >> machine. Since my computer is not what i would call young and powerful, i >> asked to make it run on a virtual machine in our own datacenter. I work >> in >> France. The Datacenter is in Poland. >> >> What was it again ? Non-Transactionnal Mode means " for every new entity >> we >> write it immediately on disk ", it meant for every entry we were eating >> the >> latency between our building in France and the datacenter in Poland. >> >> We made a proper uber-jar to run the generation code on the very same >> machine holding the Orient DB server's instance. >> We did some simple benchmark to check how the total execution time would >> behave depending on the transaction mode and location of the program. >> >> Job Place - Transactionnal : 900 secs (i don't have the real number, i >> just >> know its around that, sorry.) >> Job Place - Non-Transactionnal : more than 54000 secs >> Datacenter - Transactionnal : 212 secs >> Datacenter - Non-Transactionnal : 2700 secs (i don't have the real >> number, >> i just know its around that, sorry.) >> >> So thanks to executing the code from the right place we avoided some HUGE >> loss of times. The Non-Transactionnal mode is slower but your promess was >> kept, it runs with a constant amount of RAM, that means if we want to >> generate 10 millions or even 50 millions of entities we can in a >> reasonnable time so i would guess it's fine. >> >> Last question and i think this case will be closed (at least for me) : >> >> The OrientDB Documentation warns in >> http://orientdb.com/docs/last/Performance-Tuning.html#wise-u >> se-of-transactions >> that : >> >> "Transactions slow down massive inserts unless you're using a "remote" >> > connection. In that case it speeds up all the insertion because the >> > client/server communication happens only at commit time." >> >> We can indeed see it in effect when we run our little benchmark >> (Transactionnal - 212 VS Non-Transactionnal 2700) , are we in a >> difference >> of speed that is to be expected ? Or does something still feels off ? >> >> Thanks again for your time, >> >> Cyprien Gottstein >> Luca Garulli <l.ga...@orientdb.com>: Jan 05 11:06PM +0100 >> >> Hi Cyprien, >> >> Glad you solved it. >> >> With remote and/or graph operations, specially when you add multiple >> edges, >> transaction always help. Before 2.2 transactions didn't run in parallel, >> but after 2.2 they can. In facts, this is my next question. Are you >> running >> on multiple threads? >> >> Best Regards, >> >> Luca Garulli >> Founder & CEO >> OrientDB LTD <http://orientdb.com/> >> >> On 5 January 2017 at 15:44, Cyprien Gottstein <gottstei...@gmail.com> >> wrote: >> >> Back to top >> <#m_8605816414272133637_CAPrw5MEiW4xEetA8hd-qYQzfgnfdWR0q61D4=-KHmaaMQ4yfyw@mail.gmail.com_m_4313801924897894530_digest_top> >> Kotlin >> <http://groups.google.com/group/orient-database/t/e38fc28e7c2b1402?utm_source=digest&utm_medium=email> >> Roberto Franchini <r.fra...@orientdb.com>: Jan 05 12:26PM >> >> > The classic issue is that of parameterless constructors. >> > If there is demand for this, perhaps with some guidance, I could write >> and >> > share a binding module? >> >> I'm playing with Kotlin and OrientDB, but with the plain graph or document >> api. >> I guess you're talking about the object api. >> Can you share some examples? >> -- >> Best regards, >> >> Roberto Franchini >> >> OrientDB LTD - http://orientdb.com >> Back to top >> <#m_8605816414272133637_CAPrw5MEiW4xEetA8hd-qYQzfgnfdWR0q61D4=-KHmaaMQ4yfyw@mail.gmail.com_m_4313801924897894530_digest_top> >> Reached maximum number of concurrent connections >> <http://groups.google.com/group/orient-database/t/88aa696b03298aeb?utm_source=digest&utm_medium=email> >> Claudio Massi <massi....@gmail.com>: Jan 05 03:24AM -0800 >> >> This is a sample multithreaded java code (not scala) which fails with "No >> more resources available in pool" if you do not use db.close() >> >> import com.orientechnologies.orient.core.db.document.ODatabaseDocum >> entPool; >> import com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx; >> import com.orientechnologies.orient.core.record.impl.ODocument; >> import com.orientechnologies.orient.core.sql.query.OSQLSynchQuery; >> >> public class ThreadExample { >> >> private static final OSQLSynchQuery query = new OSQLSynchQuery("SELECT >> FROM V"); >> public static void main(String[] args) { >> >> for (int i = 0; i < 100; i++) { >> new Thread("" + i) { >> public void run() { >> >> // ODatabaseDocumentTx db = new >> ODatabaseDocumentTx("remote:localhost/GratefulDeadConcerts").open("admin", >> >> "admin"); >> // or use pool >> ODatabaseDocumentTx db = >> ODatabaseDocumentPool.global(1,40).acquire("remote:localhost/GratefulDeadConcerts", >> >> "admin", "admin"); >> >> System.out.println(" 1 -- Thread: " + getName() + " >> running"); >> db.query(query); >> // db.close(); // if you do not close it will fail >> with : No more resources available in pool (max=40) >> >> try { >> Thread.sleep(1000); >> } catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } >> }.start(); >> } >> } >> } >> >> >> com.orientechnologies.common.concur.lock.OLockException: No more >> resources >> available in pool (max=40). Requested resource: >> remote:localhost/GratefulDeadConcerts >> at >> com.orientechnologies.common.concur.resource.OResourcePool.g >> etResource(OResourcePool.java:70) >> at >> com.orientechnologies.common.concur.resource.OReentrantResou >> rcePool.getResource(OReentrantResourcePool.java:84) >> at >> com.orientechnologies.orient.core.db.ODatabasePoolAbstract.a >> cquire(ODatabasePoolAbstract.java:158) >> at >> com.orientechnologies.orient.core.db.ODatabasePoolAbstract.a >> cquire(ODatabasePoolAbstract.java:138) >> at >> com.orientechnologies.orient.core.db.ODatabasePoolBase.acqui >> re(ODatabasePoolBase.java:128) >> at ThreadExample$1.run(ThreadExample.java:22) >> >> >> Il giorno mercoledì 4 gennaio 2017 15:19:46 UTC+1, >> leon...@adimplere.com.br >> ha scritto: >> Back to top >> <#m_8605816414272133637_CAPrw5MEiW4xEetA8hd-qYQzfgnfdWR0q61D4=-KHmaaMQ4yfyw@mail.gmail.com_m_4313801924897894530_digest_top> >> You received this digest because you're subscribed to updates for this >> group. You can change your settings on the group membership page >> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/orient-database/join> >> . >> To unsubscribe from this group and stop receiving emails from it send an >> email to orient-databa...@googlegroups.com. >> >> >> -- > > --- > 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.
