That's too bad. If anyone from ODB is reading this thread, please make documentation a higher priority! This is too complex of a product to learn entirely by trial-and-error. In this particular case, my preference would be to use custom JS functions, but after burning several days trying to guess how to make it work, I ended up settling on a custom SQL function instead (and I'm a JS expert).
So far, I've not been able to identify any case where I need to traverse "upwards". To aggregate, all queries still start at the "root". Given that, I only need uni-directional links, but the links need to be "identified" with their time unit value (i.e. if we're at the month level linking to days, I need to know what day the link refers to). That leaves me with a LINKMAP (using the key as the time unit value) or an edge with a property. So even with the proposed but as yet unimplemented uni-direction links, it would still be a heavier solution than the LINKMAP. Yes, I'm considering some form of pre-allocation, although I'm not yet convinced that this is much better from a performance standpoint. What I do think will help is to pre-allocate space for the LINKMAP in each record when its first created. This comes back to part of my other questions on how much space is actually used on disk for various property types. For example, to make the LINKMAP updates most efficient, I'd want to pre-allocate enough space so the *many *updates don't each end up moving the record (rather than updating it in place). As it stands, I'm having to determine this through experimentation rather than just reading the docs (which are apparently not just incomplete but also out of date), so I don't have a solution yet. On Mon, Jun 6, 2016 at 12:48 AM, 'scott molinari' via OrientDB < orient-database@googlegroups.com> wrote: > No. Not aware of any more docs on JS custom functions. > > I am still uncertain about not using edges and vertexes. For instance, how > would you do aggregations (if you do need them) without being able to > traverse upward in the hierarchy? You're basically limiting yourself, > aren't you? > > The only thing that comes to mind, which might help is pre-allocating, > say, a day's worth of records. So, create the time based nodes before the > time actually hits (the day before?), then it is a matter of only updating > the nodes according to the timestamp of the data, once the data is created. > This could be like your current batch job, only done earlier to pre-build > the time series hierarchy. This seems plausible to me, because the time > series data is a fixed or rather known data structure. The only > disadvantage is if your time based data has holes in time, meaning, you > don't have data for every minute of the day, you'd have nodes with no data. > But, theoretically, you could clean those up the day after too. I don't > know. Just throwing out some ideas...:-) > > Scott > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "OrientDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/orient-database/21wTp42oZEI/unsubscribe. > To unsubscribe from this group and all its topics, 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.
