Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Schema Refactor: move property managemet from per class to per database #2579

Closed
tglman opened this Issue · 4 comments

5 participants

@tglman
Collaborator

Refactor the property management to make them independent from the OClass and unique by pair:"name:OType" in the whole database.

The OClass should refer to the global properties and not have them embedded.
The properties should be kept stored in the metadata independently to the OClass reference, together with the "schemaless property".

pro:

  • Easy migration from schemafull to schemaless and opposite.
  • Use the a global property identifier for the Schemafull Serialization.

cons:

  • On property delete should be check the whole db for use.

Similar pattern is used in the Semantic Schemas ex: http://schema.org/address

@lvca lvca added this to the 2.0rc1 milestone
@maggiolo00 maggiolo00 was assigned by lvca
@maggiolo00 maggiolo00 was unassigned by lvca
@tglman tglman was assigned by lvca
@phpnode

+1 for this, this way RDF concepts can map even more neatly to OrientDB

@tglman
Collaborator

implemented

@tglman tglman closed this
@PhantomYdn
Collaborator

Tglman,

Could you please take a look into following issue?
#2521

This issue seems to me the first step for discussed in that issue. Is this right? Are you supporting ideas described in that issue?

@PhantomYdn
Collaborator

Tglman,

Thanks for your reply in issue #2521!
But I have some concern regarding this one. It seems to me that moving property management from class to DB significantly narrows functionality. Let me explain.

For example we have several classes ("ClassA" and "ClassB") and each of them have property "name" of STRING type. It looks OK to have "links" from ClassA and ClassB to a single property "name:STRING".
But you are loosing ability to specify meta parameters on a properties on per class basis. For example if on application layer you should store somewhere in a meta model "validation rules" or "visialisation characteristics" on per class->property basis - you can't do that! It'll not be possible, for example, to have max 25 chars in name for ClassA and max 100 chars in name for ClassB.

I'm working on data-warehousing system Orienteer (https://github.com/PhantomYdn/Orienteer). This system use pretty natural for OrientDB notation and approach. And on other hand, I'm trying to provide quite generic functionality to work with objects in the system: for example user is able to select "property" which will play role of name of a object (object's name is used in links to a object) or select other "property" which play role of "link to parent" or "links o child". Alos it's possible to specify on a property how that property should be "rendered" and how it can be "modified". And it's done through custom parameters on properties, but it's assumed that properties managed on class layer. If they will be "shared" among classes: that will break functionality a lot...

But I have proposal.
To have ability to "share" properties between classes is cool in any case. It'll be helpfull even in Orienteer to let users "make less" in properties configuration if they can be share between classes. But there should be a possibility to have different properties with the same "name" on different classes. To allow that: some other field a long with "property name" and "property type" should be used in PK. I recommend to let users manually specify that additional "thing" if they want to limit visibility of that property to some particular class or even subset of classes. Something like "PK suffix".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.