Luigi Dell'Aquila
Luigi Dell'Aquila
Hi all +1 to the general idea, the word `cluster` is definitely misleading. Anyway I don't like `shard` very much, as it has the same disadvantages of `cluster`: a shard...
+1 for `segment`, also `chunk` is not bad, but I agree with you that it's less elegant. I agree with you that relating the name to the implementation is not...
I don't like "connect/disconnect" very much as a name, but the concept is excellent
## Implementation proposal ### New interfaces and classes ``` java interface OElement extends OIdentifiable { public void setProperty(String name, Object val); public Object getProperty(String name); public void delete(); public void...
+1 for db.save() db.delete() We have to define the db interface as well, and the expected behaviors. Eg. how does a db.delete(vertex) affect the POJOs? Does it also disconnect the...
New proposal for OElement: ``` java interface OElement extends OIdentifiable { public void setProperty(String name, Object val); public Object getProperty(String name); public Optional asDocument(); public Optional asVertex(); public Optional asEdge();...
From last discussion with @tglman: OElement and OIdentifiable should remain two different hierarchies, because result sets could return projections, that are OElement instances, but do not have an identity. ```...
@lvca right, there is something missing here, the isDocument() is related to https://github.com/orientechnologies/orientdb-labs/issues/5 The idea is that a result set will return OResult, that is an OElement but not and...
Hi @lvca The only point of this OEP is to have a common hierarchy between Document and Vertex/Edge, use a common API and avoid encapsulation. I think this hierarchy should...
Actually there is no need for OVertex to extend ODocument, I just need it to implement OElement and OIdentifiable. Users should only use interfaces in next releases, so no ODocument...