Help on query syntax

[Giovanni Adobati]

Hi, i need to extract only the results that has "hasDetail" in edge and is of @class Module.

The results of this query SELECT EXPAND( out('hasDetail) ) FROM Module WHERE code = 'module' 

are of type Module and ModuleProperty

Attached you can see the graph structure.

Thanks.

Giovanni

[alessand...@gmail.com]

Hi,

can you post your schema ?

Regards,

Alessandro

[scott molinari]

Hi Giovonni,

Sorry that I might be highjacking a bit here, but couldn't you just use regular fields within the module vertex to define the properties? I mean, properties aren't a relationship really looking at your graph. Or will the properties be relating to many other modules? Or maybe I am misunderstanding the graph principle in general?

Scott

[Giovanni Adobati]

Hi Scott, thanks for your thought.

Properties are dynamic, and has to be added or removed for each "record", so i can have different Module "record" with different moduleProperty.

May be there is a better way to do it in orientdb.

Thanks

[scott molinari]

In what sense are the properties dynamic? How many different properties will there be? I am making an assumption here, but the vertex can be schema-less, so you can store any properties you'd like at any time.  

Scott

[Giovanni Adobati]

Hi Scott,

Yes, i could also use properties in the vertex in a schema-less mode, but my properties has their field si too.

What kind of field should i use ? 

Thank you, 

Inviato da iPad

Il giorno 09/giu/2015, alle ore 20:15, scott molinari <scottam...@googlemail.com> ha scritto:

In what sense are the properties dynamic? How many different properties will there be? I am making an assumption here, but the vertex can be schema-less, so you can store any properties you'd like at any time.  

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/0O_4qnz1AMI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[scott molinari]

Any field type you'd like. You can embed properties of properties, if you'd like, too. As Alessandro pointed out, to help you out, we need to know what kind of schema you are talking about. Even if it is dynamic, you must have some kind of control over, and thus knowledge of, the schema.

Scott

[Giovanni Adobati]

Hi, you can see the attachment, is it enaugh ?

Thanks

[scott molinari]

To me, pretty much all of the pink nodes should be properties of a single vertex. For instance, the ID property is already a given from the database, the RID. Your normalization into a graph is basically going overboard and will cause way too much complexity unnecessarily. 

What other relationships do the modules have to other vertices/ records?

Scott

 

[alessand...@gmail.com]

Hi Giovanni,

I have tried the query SELECT EXPAND( out('hasDetail') ) FROM Module WHERE code = 'Module'

and I have got only the vertex Module with the code Module

Regards,

Alessandro

[Giovanni Adobati]

Hi Alessandro, Scott

Yes, i did a double check and found an error in my sql, there was not the closure apex on hasDetail, so the query now is ok, thank you a lot.

Thanks also to Scott, i really appreciate your thoughts regarding the model i'm using.

I'm new to orientDb, i'm doing a little bit of effort to understand the graph / document model mixed together.

let me explain what i would like to try to do with OrientDb

Starting from Centrico  (You can see it  centrico.it ) platform that use mysql i'm doing some test in order to understand how orientDb can help on making Centrico more scalable in regarding of performance and in architecture.

Centrico is: 

Multitenant , Multilingual

The customer can add up to 20 fields into the contacts record.

What i would like to do with OrientDB for Centrico should be:

Multitenant

Multilingual

Design driven application

Architecture free ( From the developer but also from the customer side.) add new fields , objects ( Crud components )

So the very first step i'm  doing is to design a builder of crud interface 

Builder because the application should be ( Metadata-Driven )

Do you have some suggestion on the database architecture ?

At this moment i developed an easy application with vaadin and orientDB you can see a screen shot.

so, with this application i cal also design the modules ( Crud ).

[scott molinari]

Ok, now we are getting closer. 

So only the contact object will allow custom fields? What about custom objects relating to the standard contact object? Funny, I am working on a similar idea.

I'll go with what you've said for now. 

From a database architectural standpoint, you will need some form of tenancy descriptor or metadata and this will need to be centralized. Centralizing is always something that fights against scale, but just for the  tenancy metadata, the overhead isn't too bad. So, now that you can retrieve the "tenant" metadata, you need to decide how to store and retrieve each tenant's own data. That could be at database level (1 database per tenant), class level (some prefix key in the names of each class, for instance), or at the record/vertex level with a property field holding the tenant key. All choices have advantages and disadvantages. I am not entirely sure about them in an OrientDB system either. However, for us, since we decided to go with a database per tenant, it doesn't matter. Your use case might vary.   

So, aside from your decision on tenancy control, you must also contend with the custom fields. I believe the only way to do this effectively in any document storage is to use key/ value pairs as subdocuments. Here an example. 

customFields : [ 

                       { k : "Customer's Maiden Name", v : "Miller" }, 

                       { k : "Child's Full Name", v : "Christa Smith" }, 

                       { k : "Child's Birth Date", v : 128998232389 },

                       { k : "Home Phone", v : "+1-555-123-2345" } ]

There are inherent advantages and some disadvantages to this method of storing custom field. 

Advantages: 

1. You only need one index. 

2. Querying shouldn't be too hard.

3. The fields and field types can be freely created without a lot of issue on schema. You also aren't limited to 20. You can allow 100s. 

Disadvantages:

1. You must also keep some form of metadata (mapping) of the fields for each tenant somewhere, so you know what it is they are storing and retrieving and can display it properly. (this is actually unavoidable anyway). 

2. You have more data in the DB than is actually needed, bloating it up a bit (all the k and v field names) 

3. Creating queries to insert and update gets more complicated. 

The multilingual part can mean two things. The application text i.e. field names, need translation or the actual content (the field values) need translation. This is a bit more tricky. For the field names, I'd centralize/ normalize them too. And for the content, you could have multiple subdocuments with the translated values, when they need translation. Which values are translated or not would be metadata again. 

How this all actually fits best or if it fits best in this form in OrientDB is something I am still working on myself. 

Hope that helps. 

Scott

[Giovanni Adobati]

Hi Scott,

Yes, extra fields only on contacts is not enough for my customer needs.

For multitenancy i prefer to have some centralized, Centrico has also a “server” application that schedule some operation on db that are cross tenant.

What do you think on have an object Tenant that can have some fields that are cross tenant and cross object, for instance tenantId, datetime creation, user creation, datetime edit, user edit and so on…

then each object extends the Tenant object

Thanks.

Giovanni

Il giorno 11/giu/2015, alle ore 13:08, scott molinari <scottam...@googlemail.com> ha scritto:

Ok, now we are getting closer. 

So only the contact object will allow custom fields? What about custom objects relating to the standard contact object? Funny, I am working on a similar idea.

I'll go with what you've said for now. 

From a database architectural standpoint, you will need some form of tenancy descriptor or metadata and this will need to be centralized. Centralizing is always something that fights against scale, but just for the  tenancy metadata, the overhead isn't too bad. So, now that you can retrieve the "tenant" metadata, you need to decide how to store and retrieve each tenant's own data. That could be at database level (1 database per tenant), class level (some prefix key in the names of each class, for instance), or at the record/vertex level with a property field holding the tenant key. All choices have advantages and disadvantages. I am not entirely sure about them in an OrientDB system either. However, since we decided to go with a database per tenant, it doesn't matter.  

So, aside from your decision on tenancy control, you must also contend with the custom fields. I believe the only way to do this effectively in any document storage is to use key/ value pairs as subdocuments. Here an example. 

customFields : [ 

                       { k : "Customer's Maiden Name", v : "Miller" }, 

                       { k : "Child's Full Name", v : "Christa Smith" }, 

                       { k : "Child's Birth Date", v : 128998232389 },

                       { k : "Home Phone", v : "+1-555-123-2345" } ]

There are inherent advantages and some disadvantages to this method of storing custom field. 

Advantages: 

1. You only need one index. 

2. Querying shouldn't be too hard.

3. The fields and field types can be freely created without a lot of issue on schema. You also aren't limited to 20. You can allow 100s. 

Disadvantages:

1. You must also keep some form of metadata (mapping) of the fields for each tenant somewhere, so you know what it is they are storing and retrieving and can display it properly. (this is actually unavoidable anyway). 

2. You have more data in the DB than is actually needed, bloating it up a bit (all the k and v field names) 

3. Creating queries to insert and update gets more complicated. 

The multilingual part can mean two things. The application text i.e. field names, need translation or the actual content (the field values) need translation. This is a bit more tricky. For the field names, I'd centralize/ normalize them too. And for the content, you could have multiple subdocuments with the translated values, when they need translation. Which values are translated or not would be metadata again. 

How this all actually fits best or if it fits best in this form in OrientDB is something I am still working on myself. 

Hope that helps. 

Scott

[scott molinari]

Like I said, I am not sure how this would best fit with OrientDB as the database. What language are you using? Your idea sounds like the vertex/ record level tenancy control and yes, I think that could work as you suggest.I am just not sure if it should be called the "tenant" base class or just "baseClass" though. 

Scott

[Giovanni Adobati]

May be some one from OrientDB can help on this.

Bye

Il giorno 11/giu/2015, alle ore 15:54, scott molinari <scottam...@googlemail.com> ha scritto:

Like I said, I am not sure how this would best fit with OrientDB as the database. What language are you using? Your idea sounds like the vertex/ record level tenancy control and yes, I think that could work as you suggest.I am just not sure if it should be called the "tenant" base class or just "baseClass" though. 

Scott