Re: [orientdb] Re: Concurrency during UPDATE ADD operation

OK. That makes sense. I thought those operations were "inherently atomic", but they are really just doing an update like any other. The commit/retry is fine, I was just trying to make sure I understood. On Thu, Nov 16, 2017 at 2:17 AM, Luigi Dell'Aquila < luigi.dellaqu...@gmail.com> wrote: > Hi

Re: [orientdb] Syntax for ADD operation with collection of maps?

Looks like a bug; report opened: https://github.com/orientechnologies/orientjs/issues/285 On Mon, Nov 13, 2017 at 2:20 AM, Luigi Dell'Aquila < luigi.dellaqu...@gmail.com> wrote: > Hi Eric, > > The correct syntax should be just > > UPDATE x ADD list = {"ddd":444, "dd":44} > > If it doesn't work,

Re: [orientdb] Behavior of elements in EMBEDDEDLIST

Thanks for the quick response. I'm not familiar with that option. What's the syntax of the create property statement to do this? On Thu, Oct 26, 2017 at 8:25 AM, Luigi Dell'Aquila < luigi.dellaqu...@gmail.com> wrote: > Hi Eric, > > Try to define the property as EMBEDDEDMAP with LINKEDTYPE =

Re: [orientdb] Re: "Pinning" a table in memory

h the old > LOCAL storage engine. > > Anyway, even if implementing this should be quite trivial, Andrey could > have a better idea about how to do that. > > Best Regards, > > Luca Garulli > Founder & CEO > OrientDB LTD <http://orientdb.com/> > > > On 2

Re: [orientdb] Re: "Pinning" a table in memory

@Luca: How does it help that it used to exist in LOCAL storage? What I'm looking for is a class in PLOCAL that works in every way the same as any other class (specifically including replication), but is guaranteed to be 100% in memory and has the option of being persisted to disk or not. --Eric

Re: [orientdb] Re: "Pinning" a table in memory

@scott: No problem--thanks! On Wed, Jul 20, 2016 at 9:41 AM, 'scott molinari' via OrientDB < orient-database@googlegroups.com> wrote: > Hey Eric. Already done! > > https://github.com/orientechnologies/orientdb/issues/6447 > > Hope you don't mind. > > Scott > > -- > > --- > You received this

Re: [orientdb] Re: "Pinning" a table in memory

OK. I'll do that later today. If anyone has any specific suggestions you'd like to see as part of this request, please reply to this thread in the mean time (and please label as "critical", "important", and "nice to have"). --Eric On Wed, Jul 20, 2016 at 3:09 AM, Andrey Lomakin

Re: [orientdb] Re: Support for Lucene 6 3D (nD) Spatial Indexes

Thanks Roberto. This isn't a current need for us (2D point-mapping is fine for now), but it is important for our database architecture. On that point (no pun intended), do you see any reason why OPoint and related Geo objects wouldn't just be "extended" to handle 3D, 4D, nD points in the future by

Re: [orientdb] Re: OrientDB Storage Overhead

OK. So the space used is just the ID itself? How many bytes is the ID? On Wed, Jun 8, 2016 at 1:23 AM, Andrey Lomakin wrote: > Hi, > >The second part is new--whether there is a difference between not adding > a property and setting it to NULL > Yes, there is the

Re: [orientdb] Re: RETURN @rid doesn't work as documented

Ugh and sigh. I had considered that (and tried it for a short time), but ultimately decided I didn't have the bandwidth to go through that learning curve. On Tue, Jun 7, 2016 at 2:04 AM, 'scott molinari' via OrientDB < orient-database@googlegroups.com> wrote: > Yeah, I see what you mean. I

Re: [orientdb] Re: RETURN @rid doesn't work as documented

Yes, but unless I'm totally missing it, neither the old or the new documentation really document the custom JS function environment. There are some code examples that use some of the objects and functions, but, for example (from Alessandro's example code), getId() and commit() are not documented

Re: [orientdb] Re: RETURN @rid doesn't work as documented

Thank you. Very interesting. The first link is very useful, but it was apparently removed from the current documentation. Wonder why... The second link is one I've seen, but it's more high-level, focused on the process of creating functions in Studio. On Mon, Jun 6, 2016 at 10:52 AM, 'scott

Re: [orientdb] Re: RETURN @rid doesn't work as documented

This is very helpful, but how do you know the properties/functions available on 'orient', 'g', and 'b' (i.e. command, commit, getId, etc.)? I can't find this documented anywhere, short of a few examples here and there (some of which conflict with each other)? Also, I'm assuming that this is the

Re: [orientdb] Re: OrientDB Storage Overhead

The first part, yes (I'm just stating my understanding that properties defined in the schema that are not added to a record incur no overhead). The second part is new--whether there is a difference between not adding a property and setting it to NULL. In MSSQL, for example, there is no difference,

Re: [orientdb] Re: What is the fastest way to insert a group of linked documents?

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

Re: [orientdb] Re: RETURN @rid doesn't work as documented

Thank you, but actually, that doesn't get me what I'm looking for. True, rid is a string in the JSON, but I'm still not able to get the rid as a simple variable. What is need is just "#xx:yy", not part of a JSON structure. In one attempt at a Javascript function, I used variations of

Re: [orientdb] Re: OrientDB Storage Overhead

Another sub-question on this topic: I assume that if you don't add the property at all, then it add zero bytes to the record--correct? But if you add a fixed-size property (i.e. SHORT, INTERGER, LONG, etc.) to a record with its value explicitly set to NULL, does that take up the same amount of

Re: [orientdb] Re: What is the fastest way to insert a group of linked documents?

The time-series data is stored in a "cascade" of linked records (I'm currently using LINKMAPs in documents, but the same could be done with vertexes and edges); there are several possible structures, but one is root->year->month->day->hour->minute->sample (this one allowing for multiple samples

Re: [orientdb] Re: UPSERT PUT to a LINKMAP property

Ah so. Good catch. Yes, the position of the RETURN clause does appear to matter. So making this change does eliminate the exception, but unfortunately, it doesn't produce the desired result. In this case, no record is returned *except *when the UPDATE succeeds. What I need is essentially the

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] Re: Not able to select BYTE type for field via ODB Studio

Ah so. It's a quirk when using IE (it works as expected on Chrome), but the table display still shows [binary-data] for BYTE-type properties. On Mon, May 23, 2016 at 9:26 AM, wrote: > version 2.2 > browser chrome > > -- > > --- > You received this message because you

Re: [orientdb] What happenes to edges if I delete a vertex.

Thanks Scott. That makes sense. But it brings up another question that I've had for some time. I've never actually created an ODB document database. As I see it, there's really no reason to, since a graph database still retains all of the features of a document database (at least the ones that I

Re: [orientdb] Hot Alignment still not recommended?

Thanks for the details Luca. Just out of curiosity, are you planning to phase out HZ over time or are you generally satisfied with this solution? Of course the challenge with load-balancing in a distributed environment (and probably moreso with a writeQuroum < totalNodes) is the trade-off between

Re: [orientdb] Re: Is OrientDB a good choice for a financial system?

Yes, that's a good point. Since the OP's application was described as a financial application, I assumed that these documents were created once and essentially never deleted or "moved around", so I didn't figure there was any need to worry about referential integrity. That said, using edges may

Re: [orientdb] Re: Graph Design Question

@Luca: Yes, that's understood. My question was not about what OrientDB *can *do, it was really more about whether there were really any good reasons to ever use properties on edges. So far, every use-case I've come across where edge properties were a possible design solution, it seems like

Re: [orientdb] Re: Graph Design Question

2015-07-31 18:26 GMT+02:00 Eric Lenington e...@24x8.com: @Luca: Yes, that's understood. My question was not about what OrientDB *can *do, it was really more about whether there were really any good reasons to ever use properties on edges. So far, every use-case I've come across where edge

Re: [orientdb] Re: Curious about Time Series Use Case

@Luigi: Excellent. Thanks for the quick and detailed response! --Eric On Wed, Jul 22, 2015 at 8:21 AM, Luigi Dell'Aquila luigi.dellaqu...@gmail.com wrote: Hi Eric, at this stage the query executor is not smart enough to understand that the two syntaxes have the same meaning, it just

Re: [orientdb] Re: Curious about Time Series Use Case

@Alessandro: Ah, very nice! To me, this syntax actually makes more sense. :) But regardless, it also seems more flexible. For example, I think this should be possible, right? SELECT expand(out('haveMonth')[month=3].out('haveDay')[day=20].out('haveHour')[hour=10 and hour=20].out('haveLogs')) FROM