Hmmm. So Luca says lightweight edges are much faster, but Riccardo says his
benchmark results show no difference since OrientDB 2.0. Surely this is a
use-case issue? I've been personally very interested in understanding more
about the use-cases of lightweight vs. regular edges. I've been scourin
Just out of curiosity, why would you want to do this? What are you trying
to accomplish?
--Eric
On Thursday, July 9, 2015 at 1:13:24 PM UTC-5, bullson wrote:
>
> Hi,
> is it possible to create a Link between a Document and a link?
> When i try this, i get the error message, that the id of the li
In an article I was reading about neo4j, they suggested that this:
person -> contact_email -> contact
person -> contact_phone -> contact
...
is preferred to this:
person -> contact[property:email] -> contact
person -> contact[property:phone] -> contact
(Pay no attention to the syntax--just pseu
Yes, I've read that (and lots of other stuff on edges, lightweight and
regular). The question goes beyond that. Taken by itself, a single
lightweight edge is (or should be) faster and more efficient than a single
edge with a property, but what about multiple lightweight edges vs a single
edge w
@Scott: In my example, "email" and "phone" are not the actual email address
or phone number, they are edge "types". The idea being that there is one
edge class with a "type" property that defines what kind of contact record
is being referenced (the actual contact record would contain the email
@Scott: The article is part of an ebook by O'Reilly called Graph Databases.
It's available for free from http://neo4j.com/books/graph-databases/
I think you might be misunderstanding my objective. Person and Contact both
extend V, and each contains appropriate properties for their respective
ob
@xvik: Correct. And the idea of extending a common base class and then
including @class in the WHERE clause is essentially what I was looking at
for the "no property" approach. I suppose the follow-on question here is
whether it's faster to test @class vs a property (again, this example would
n
On Wed, Jul 8, 2015 at 6:10 AM, Riccardo Tasso > wrote:
>
>>
>> 2015-07-08 5:13 GMT+02:00 Eric24 >:
>>
>>> Riccardo says his benchmark results show no difference since OrientDB 2.0
>>
>>
>> That's not my benchmark: Craign said so (
>&
Since you are using the terms 'links' and 'documents', I'm assuming you're
not operating in document mode, not graph mode? From what I understand,
this seems like a good graph mode use-case, where you would indeed create
'links' (actually edges) between your 'documents' (actually vertices), so
Hmmm. That's part of the challenge I've had in learning ODB and graph
databases in general--there are lots of examples that mention various
constructs without really explaining them. Surely it's possible to include
a property in a query, and if that property is a "weight" (regardless of
what it
Yep, that makes sense to my way of thinking. I assume the weight property
could also be used in an ORDER BY clause?
--Eric
On Monday, July 13, 2015 at 8:06:06 AM UTC-5, Riccardo Tasso wrote:
>
>
> 2015-07-13 14:58 GMT+02:00 Eric24 >:
>
>> Surely it's possible to inc
Hi all--
I'm looking for some advice on pros/cons/designs for implementing a queue
in ODB. The queue stores messages in a more-or-less FIFO manner based on
the individual message priority (an integer), with the possibility that
some messages may need to be retried over a period of time, but ulti
I want to check my thinking on something: It is true that the RID of a new
object of a particular class (V or E) will always be "greater than" any
previous object's RID, regardless of how "distributed" the underlying
database is? If so, can I rely on ORDERing by the RID to always return
results
cast would be make a very good HA
queue. Is there any reason I can't just directly use the same Hazelcast
instance as ODB uses?
On Monday, July 13, 2015 at 2:45:48 PM UTC-5, Eric24 wrote:
>
> Hi all--
> I'm looking for some advice on pros/cons/designs for implementing a que
Thanks for the suggestions. I'll check them out. Although my objective was
to not introduce yet another technology--that's why I was looking at
Hazelcast as a "next alternative", assuming ODB wasn't optimal for this.
Regarding Hazelcast, can you confirm my understanding that it's already
"inclu
@Richard: Just for my education, what does this syntax do?
--Eric
On Wednesday, July 15, 2015 at 9:16:30 AM UTC-5, Riccardo Tasso wrote:
>
> Hi,
>I have a query similar to the following in Orient 2.0.12:
>
> SELECT out()[group=:group]
> FROM Person
>
>
> I execute it from Java, with the follo
a filter on the out() such that only
> those vertices which contain group property = the passed value are returned
>
> hope that helps
>
> On Wednesday, July 15, 2015 at 8:38:20 PM UTC+5:30, Eric24 wrote:
>>
>> @Richard: Just for my education, what does this syntax do?
&
t need to be persistent.
--Eric
On Wednesday, July 15, 2015 at 9:10:58 AM UTC-5, Eric24 wrote:
>
> Thanks for the suggestions. I'll check them out. Although my objective was
> to not introduce yet another technology--that's why I was looking at
> Hazelcast as a "next al
t; OrientDB <http://orientdb.com/>
>
>
> On 17 July 2015 at 02:06, Eric24 > wrote:
>
>> So, MongoDB looks like a viable choice, but that means adding another
>> technology to my "stack". Disque looks interesting, but seems a little to
>> rou
As I continue to learn ODB, I come across a lot of examples that make me
think about alternative ways of doing the same thing and why the author of
the example chose the approach they did. One that I saw early on an came
back to recently was the Time Series Use Case in the docs
(http://orientdb
rtmut bischoff wrote:
>
>
>
> On Saturday, July 18, 2015 at 7:39:56 PM UTC+2, Eric24 wrote:
>
>
>> why the links between the various date parts was done using a LINKMAP
>> instead of edges? To my way of thinking, using edges would be more "graph
>> like"
Interesting. I wonder if the "bracket" syntax is even supposed to work or
if it only works with = ? Although that would seem pretty strange. I
suppose putting all of it in the WHERE clause would work fine, too, and
once the query is parsed, should produce an identical execution plan.
--Eric
On
Aha! Interesting that the bracket syntax is 4X faster than using the WHERE
clause. That's a bit surprising, as I would have thought that the query
optimizer would have arrived at the same execution plan for either syntax,
since they are functionally the same.
Anyone from Orient care to comment
"Memory storage is for testing." Really? What if I don't want anything to
persist? I would have assumed that memory storage in a cluster would be a
good alternative (and fast) for something like what you might use memcached
(or a variant) for?
--Eric
On Wednesday, July 29, 2015 at 8:30:15 AM U
I'm learning more and more about OrientDB and graph databases every day.
One question that I've seen lots of conflicting comments about across the
Internet is use-cases where SQL/RDBMS are preferred over a graph database
(most of what I've seen uses Neo4j as their graph database "foil"). I'm an
I came across a real-world example recently that seems to cry out for
"normal" edges with properties (as opposed to lightweight edges): The
simplified version is a list of people and the companies they have worked
for. It seems to me that an edge class between person and company classes
with "s
it cannot be executed on in-memory db). So
> if you want to try a distributed configuration, at least one node has to be
> a persistent one. This limitation will be removed in next releases.
>
> Thanks
>
> Luigi
>
>
> 2015-07-30 18:59 GMT+02:00 Eric24 >:
>
&
Just a thought: It seems like customerId is the property that should be
indexed here. Although if most/all of your customerIds are < 10, it may
still require a large number of records to be scanned in order to calculate
the sum. If so, the problem may just be cache size and/or disk throughpu
rement for
> mapping tables to slow this down like in SQL.
>
>
> On Friday, 31 July 2015 06:45:05 UTC+7, Eric24 wrote:
>>
>> I'm learning more and more about OrientDB and graph databases every day.
>> One question that I've seen lots of conflicting comments abou
between People and Companies. These are the
>> attributes for the edges.
>> You get the additional benefit that you don't have to know all questions
>> to be answered (as in RDMS). You just provide some basic properties and
>> leave anything else to the user.
Congrats! I'm very excited about live queries (especially with node.js)!
--
---
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...@googlegrou
Luca--
After making this change, does OrientDB actually save the ms? I was under
the impression that datetimes were stored internally as LONGs using the
standard Unix Epoch format (seconds since...).
--Eric
On Thursday, December 19, 2013 at 8:28:16 AM UTC-6, Lvc@ wrote:
>
> You can use also:
>
>
We're considering using OrientDB as a Web Session Cache (similar to how you
might use memcachd or Redis, for example), but since we already have
OrientDB "in the stack", the idea was to not introduce yet another
technology if we didn't have to. I know all the "good reasons" why
memcached and es
Just a thought (and I'm relatively new to ODB, so I invite anyone's input
if my thinking is wrong)...
When designing a data model for ODB, if you think about it in the same
terms as a relational database, you can end up with a model that's pretty
close to what you'd come up with there (as you s
I'd love to hear from Orient as to why this would take 2+ hours, on a
dataset with only 20K vertexes. That can't be considered reasonable.
On Thursday, April 21, 2016 at 5:21:20 PM UTC-5, pabloa wrote:
>
> Hello,
>
> I tried and queries worked.
> However, when I tried the 2nd query with more row
+1
--
---
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.
Is hotAlignment working now in 2.2?
On Wednesday, April 29, 2015 at 2:02:07 AM UTC-5, l.garulli wrote:
>
> Hi,
> Unfortunately hotAlignment is still not working, in the meaning that
> cannot guarantee 100% consistency of database.
>
> We are working with Hazelcast team for a more efficient soluti
/master/Release-2.2.0.md#distributed
> .
>
> Best Regards,
>
> Luca Garulli
> Founder & CEO
> OrientDB <http://orientdb.com/>
>
>
> On 7 May 2016 at 17:35, Eric24 > wrote:
>
>> Is hotAlignment working now in 2.2?
>>
>> On Wednesday, April
Luigi--
Just so I'm clear on this, you say delete using the Graph API, but it's my
understanding that if I use SQL to delete a vertex that this also deletes
any related edges. Correct or no?
--Eric
On Wednesday, May 18, 2016 at 10:32:44 AM UTC-5, Luigi Dell'Aquila wrote:
>
> Hi Piotr,
>
> If you
Can someone take a look at the question I posted yesterday on
SO:
http://stackoverflow.com/questions/37313570/troubleshooting-basic-issues-with-orientjs-orientdb-driver-for-node-js
--Eric
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To un
no matter what, even the
simplest functions like server.list() never resolve their promise. Any
ideas of even a direction I might pursue would be greatly appreciated.
On Thursday, May 19, 2016 at 7:56:17 AM UTC-5, Eric24 wrote:
>
> Can someone take a look at the question I
Thank you. And no, I didn't think of that. I assumed orientjs would be
compatible with ODB 2.2. I'll try, but if that's the case, can someone from
ODB confirm this?
On Friday, May 20, 2016 at 11:31:16 PM UTC-5, scott molinari wrote:
>
> I answered on SE, but I'll post my answer here too.
>
> Ha
Using 2.2 GA, I'm not able to select the BYTE for a field in a new class
I'm trying to create via ODB Studio (SHORT, LONG, etc. work just fine).
Also, are the single-letter values for @fieldTypes documented somewhere?
--
---
You received this message because you are subscribed to the Google G
Forgive me, because I know this question has been asked before, but it has
never really been answered (that I could find after a significant time of
searching).
I fully understand the basic sequence of events need to use orientjs:
instantiate the driver, connect to a server, select a database,
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 only
u add a property to a lightweight edge, it is
> automatically transformed to a regular edge
>
> Thanks
>
> Luigi
>
> 2016-05-24 15:55 GMT+02:00 Eric24 >:
>
>> Since this has changed since a lot of the documentation was written, I
>> want to get a definitive ans
Actually, I'd say the RIDs are very RESTful, if you do this:
.../domain.com/other-segments/{cluster}/{position}/... Since clusters are a
"superset" of a specific class (i.e. one class will have one or more
clusters), this can be thought of as identifying the target data object by
type/record. I
I have a few questions about storage overhead in ODB. If this is in the
documentation somewhere, I've not been able to find it.
1. What is the overhead (in bytes) to store any document (V or E),
regardless of any property data (and not including indices, if any)?
2. If non-mandatory pro
Thanks Scott. The RECORD* params definitely address the discrepancy between
the data written and my observed disk space growth (I left them at their
defaults, which the docs say is 1.2). So, setting these to 1 would
essentially remove any fluff from the record. That's potentially good, and
sinc
As a follow-up, I found this very interesting
article:
http://carloprad.blogspot.it/2014/03/orientdb-on-zfs-performance-analysis.html
The concept (as it relates to disk space usage, which wasn't the primary
focus of this analysis) is to essentially move the compression to the file
system (ZFS
iginal
written record size, or 100% padding)?
--Eric
On Saturday, May 28, 2016 at 11:17:57 AM UTC-5, Eric24 wrote:
>
> As a follow-up, I found this very interesting article:
> http://carloprad.blogspot.it/2014/03/orientdb-on-zfs-performance-analysis.html
>
> The concept (as
Thanks Luca, but the specific question around OVERSIZE is how it relates to
the cluster parameter RECORD_GROW_FACTOR. They seem to effectively do the
same thing and appear to be usable interchangeably. Does one take precedent
over the over? Are both factors applied (i.e. does the actual padding
I'm trying to determine the most efficient and least contentious way to do
a sort of UPSERT on a LINKMAP property. Specifically, if I try to PUT a new
item with a key value that already exists, I want the PUT to fail and leave
the existing item in place (and instead return that item to the calle
I'm running 2.2 GA. My attempt at doing this was various versions of this
(but I haven't found any combination that works):
UPDATE #14:1 PUT Options = '22', {"Action":"Test22a","Enabled":false,
"@type":"d", "@class":"VOptions"} WHERE NOT (Options CONTAINSKEY '22')
RETURN AFTER Options['22']
It
')
RETURN AFTER @this.Options['22']
But this works:
UPDATE #14:1 SET OtherProperty = 'OtherValue' RETURN AFTER
@this.Options['22']
Is it possible that the RETURN clause can't be used with a PUT operation?
On Wednesday, June 1, 2016 at 7:46:53 AM UTC-5, Eric24
return sel[0]
> } else {
> var upd=g.command("sql","update "+rid+" put "+map_name+"='"+key_name+
> "',"+key_value+" return after @this."+map_name+"['"+key_name+"']");
> return upd[0
When I do the following (or any other SQL INSERT or UPDATE operation that
supports the RETURN clause), I get the full record back, not just the RID:
INSERT INTO VMenu CONTENT {"Main":"PM", "Timeout":"PT", "Error":"PE"}
RETURN @rid
How can I get just the newly-created (or update) RID? I need to
Well, if I use RETURN @rid, I get the whole record back. Using RETURN
@class, I get back what you show in your example, which is still a JSON
object that *contains* the RID. But I was expecting RETURN @rid to return
just the RID as a simple string. In any case, there is no different between
RET
Using orientjs (or a JS or SQL function), I'm trying to insert a related
group of documents (up to six or eight at a time), so that LINKMAPs in each
document can be set as they are inserted (i.e. D1->D2->D3->D4). I'm not
wanting to use edges, because the links are only ever uni-directional and I
Time-series data is a pretty good representation of what I'm doing (see
p.22 of this
presentation:
http://www.slideshare.net/LuigiDellAquila/orientdb-time-representation).
Consider: a) there is never a need to traverse "up" from a lower-level
node; b) the data is relatively static (i.e. write
Luca (or someone from ODB)--can you provide some additional details on
this? If it's in the documentation, I can't find it, and I think these are
important things to know:
1. How does OVERSIZE relate to the cluster parameter RECORD_GROW_FACTOR?
2. What is actually stored on disk when a new
> >Does it incur any per-record overhead to define a non-mandatory property
> in the schema if that property has not been assigned a value?
> Do you mean whether we add additional information to record if field is
> absent in record itself but defined in schema, do not you ? No,
PS - Also, it appears that OVERSIZE == 0 by default (per: select
expand(classes) from metadata:schema)? Is it a "factor" (i.e.
base-record-bytes * OVERSIZE) or a number of additional padding bytes to be
added?
On Friday, June 3, 2016 at 8:49:54 AM UTC-5, Eric24 wrote:
>
> Thank
I tried a test, and apparently, the ms are saved in a DATETIME-type
property after setting the DATETIMEFORMAT as suggested. So I guess that
means it's not Unix Epoch format. Maybe it's "ms since..." stored as a
64-bit integer?
On Friday, March 18, 2016 at 11:27:57 AM
What version of Lucene is currently supported in OrientDB 2.2.0? If less
than 6.0, what would be required to support 6.0/6.0.1 (and/or if and when
is this on the road map)? If 6.0 or later, are 3D/nD spatial indexes
supported? For example, there is no enforced limit on the number of
elements th
+1
--
---
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.
Where can I find the release notes for 2.2.2?
--
---
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, v
Just out of curiosity, why do you need the allowLeadingWildcard metadata?
The example appears to show a "trailing" wildcard.
--Eric
On Monday, July 18, 2016 at 10:51:45 AM UTC-5, SavioL wrote:
>
> You can use this query:
>
> select expand(in('LTSval')) from ATS_NAMAbbr where dval LUCENE "ABS*"
>
Is there any mechanism (in ODB 2.2.x) to "pin" a specific table in a
database in memory?
Essentially, within a normal plocal disk-backed database, I want to select
a specific table that is always guaranteed to be in memory (obviously my
application is making sure that this table is maintained i
Hi @Luigi: Good to hear that you are planning ongoing improvements to
LiveQuery. Among all of the other compelling features of OrientDB, this one
is very relevant to us (and I think to an ever-increasing audience, as more
and more applications are moving from polled or user-initiated updates to
I'd be interested in this answer, too. We are getting ready to work on a
project that uses live query with node.js.
--
---
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 emai
@Luigi--
Hmmm. If the difference between traverse out('MyEdge') and
out('MyEdge').out('MyEdge') is 100X, that sounds like an opportunity for an
internal optimization. Unless there are dozens of other edges beyond the
first level in this schema, it seems that the query optimizer could figure
thi
Can anyone answer this question?
https://stackoverflow.com/questions/46536616/not-possible-to-use-server-after-db-server-use
PS - I'm not sure what the comment about opening a github request is all
about--I'm asking a question, not requesting a feature.
Here's the referenced code:
"use strict"
wrote:
>
> Hi Eric
>
> Seems a bug on session management, i've created an issue here
>
> https://github.com/orientechnologies/orientjs/issues/279
>
> 2017-10-03 16:56 GMT+02:00 Enrico Risa >:
>
>> Hi Eric
>>
>> let me check on this
>>
Using ODB 2.2.28, I have a simple Class that contains an EMBEDDEDLIST
called "data". If I update "data" like this:
UPDATE #12:4 SET data = [{"a":111}, {"b":222}, [{"c":555}, {"d":777}]]
The result of then selecting "data" from the record is this:
[{"@type":"d","@version":0,"a":111},{"@type":"d","
So is there a solution?
On Thursday, October 26, 2017 at 8:42:03 AM UTC-5, Luigi Dell'Aquila wrote:
>
> Hi Eric,
>
> The syntax is following
>
> CREATE PROPERTY ClassName.propertyName EMBEDDEDLIST EMBEDDEDMAP
>
> but I see that in your list you have a mix of maps and sublists, so I'm
> afraid it
I want to confirm that a behavior I'm observing in ODB 2.2.28 is actually
intended to work the way it appears to be, and that this behavior will be
maintained.
I'm doing an UPDATE that relies on "short-circuit evaluation" of the WHERE
clause:
UPDATE Cache CONTENT {"instance":"XYZ", "key":"JJJ",
I'm looking for a suggestion on how to construct a SELECT statement that
returns specific properties from linked classes.
I have a V class that can have one or more identical V classes linked via
standard E edges. What I'm trying to do is select the "root" V class and
have the query return prop
In other words, with ODB 2.2+ (and 3,0), is there really any downside to
using the V superclass for all classes, even if the resulting "document"
class will never be used in a graph context?
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To
Works perfectly. Thanks!
On Monday, October 30, 2017 at 2:59:13 AM UTC-5, Luigi Dell'Aquila wrote:
>
> Hi Eric,
>
> With plain SELECT:
>
> SELECT inV().vertexProp1, inV().vertexProp2, edgeProp1, edgeProp2 from (
> select expand(outE("TheEdgeClass")) FROM V WHERE foo = ?
> )
>
> With MATCH:
>
>
Here is an example of what I get back from an orient.js 'exec' call:
{
"status": {
"code": 0,
"sessionId": 123
},
"results": [{
"type": "f",
"content": "1"
}]
}
I've not been able to find any documentation on this. Is that available
anywhere? While I can "reverse engineer" some
If two clients perform an UPDATE ADD on the same record at the same time,
do both ADD operations always succeed without an exception (since they
can't conflict with each other by definition)? What about two PUT
operations, with different/non-conflicting keys?
--
---
You received this message
2017 at 6:53:27 PM UTC-6, Eric24 wrote:
>
> If two clients perform an UPDATE ADD on the same record at the same time,
> do both ADD operations always succeed without an exception (since they
> can't conflict with each other by definition)? What about two PUT
> operations, with dif
I can't figure out the proper SQL syntax for adding a map to a collection.
For example, the record property "list" is "[{"aaa":, "aa":11},
{"bbb":222, "bb":22}, {"ccc":333, "cc":33}]. I can easily create and query
this property, but how do I add {"ddd":444, "dd":44} to this collection?
UPDA
While it's easy enough to delete rows from a manual index by @rid
(using DELETE FROM INDEX:testindex WHERE rid = #10:4), is the index
structured in a way that this is efficient? In other words, does ODB have
to essentially read through the entire index to find all of the occurrences
of @rid #10
It has been mentioned many times that using lightweight edges is "more
difficult" with SQL. Can anyone provide specific examples of when this is
true (i.e. what are the SQL issues created by using them)?
I ask because just about everything I've tried with lightweight edges works
the same way wi
I have a class that contains a LINKMAP field called links. This class is
used recursively to create arbitrary hierarchical groupings (something like
the time-series example, but not with the fixed year/month/day structure).
A query like this:
select expand(links['2017'].links['07'].links['15'].
- you cannot count them, eg. SELECT FROM E will return a wrong result
>
> The DELETE VERTEX is supposed to work fine though, if you have a test case
> that proves the problem please submit it, I'll check it asap
>
> Thanks
>
> Luigi
>
>
> 2017-11-13 19:21 GMT+01:00 Er
d.
>
> I hope it helps
>
> Thanks
>
> Luigi
>
>
> 2017-11-12 19:11 GMT+01:00 Eric24 >:
>
>> To follow up on this, would LOCK RECORD be necessary? If I didn't want to
>> incur the lock overhead, is there a way to set the concurrency strategy on
I couldn't find any information on this specifically, but I know that some
databases support no-downtime upgrades when running in a clustered
configuration (i.e. idle/quiesce one node at a time, upgrade that node, and
reintroduce it to the cluster). Is this possible with ODB 2.2.30? If so, is
t
It's easy to add more storage capacity to a Class by simple creating and
adding a new Cluster to that Class. There is also a way to remove a Cluster
from a Class, but this doesn't "redistribute" the data in that Cluster to
other Clusters in the Class. Is that function supported "automatically"
According to the 3.0 documentation
(http://orientdb.com/docs/3.0.x/sql/SQL-Update.html), ADD|PUT (and
INCREMENT, which I don't use) have been removed from the SQL UPDATE syntax.
Is there an alternative way in 3.0 to modify a Collection or Map, rather
than overwrite it completely with SET?
Also
Using this example from the documentation on time-series data:
SELECT expand( month[3].day[20].hour[10].logs ) FROM Year WHERE year =
"2012"
How would I get all of the RIDs (as a list or record set) that were
"traversed" by this query? I realize I can do a TRAVERSE, but the problem
is that thi
Thanks Luigi; makes perfect sense. Is this syntax also supported on 2.2.x?
On Tuesday, January 2, 2018 at 2:23:32 AM UTC-6, Luigi Dell'Aquila wrote:
>
> Hi Eric,
>
> The alternatives are:
>
>
> PUT: just use dot notation
>
> UPDATE ADoc PUT aMap = "aKey", "aValue"
>
> can be written as
>
> UPDATE
I'm running a query that sets a field in a target record to a calculated
value based on another field in that same record. This is a simplified
version of my query:
UPDATE #25:0 SET publish = eval('@this.expires + 2')
This works, but I just wanted to see if using the eval() function in this
wa
I have a generic (non-V) class with a LINKMAP field that links a chain of
time-series data. Each record links to the next record based on a key of
the next month/day/hour/etc. and a value of the @rid of the next record. I
could use edges (non-lightweight, with a single property the same as the
+1
On Monday, February 12, 2018 at 4:37:11 PM UTC-6, Buntu Dev wrote:
>
>
> Wanted to check if there is any existing OrientDB Slack channel to get the
> interested parties to come together to discuss and help with OrientDB,
> please let me know.
>
> Thanks!
>
--
---
You received this message
If I need to store JSON in an ODB record, but I don't need to query within
it (i.e. various JSON content treated as opaque by ODB), is it more
efficient to stored it as a string or as an Embedded ORecord?
On a related topic, where is "@type" and its acceptable values documented?
I can't find it
After several days and lots of views, it appears I've stumped
StackOverflow. Can anyone can shed any light on either of these issues?
-
https://stackoverflow.com/questions/49459032/orientdb-how-to-use-match-in-an-update-operation
-
https://stackoverflow.com/questions/49460138/orie
99 matches
Mail list logo
