Hi Luigi, A few follow up questions on property alterations - In a command like "alter property X.p0 name p1", there seems to be a mix of schema change and document change operations:
1) drop property p0 2) create property p1 3) Copy values from p0 to p1 How does this work transactionally? i.e. is it possible for a schema change to occur but not the document change and vice-versa when I run "alter property X.p0 name p1"? It also appears that if there is an index for X.p0, it remains in place after changing p0 to p1. The p0 property is dropped though. Does the index need to be removed in a separate step? --- I also experimented with alter property Test0.p0 type string (originally p0 was created as a long). However, I get a conversion error (cannot convert long to string), which seems odd since the conversion seems compatible. Would you recommend handling these type change operations manually instead via a series of schema and document and index changes? In any case, the transaction issue still remains when there is mix of schema & document & index change operations, correct? Thanks, --Harish. On Friday, October 30, 2015 at 1:40:45 AM UTC-7, Luigi Dell'Aquila wrote: > > Hi Harish, > > Using the short name in your use case seems to be a perfect fit. This way > you will avoid all the consequences of changing class name, especially with > cluster and index names. > About property names, unfortunately there is no support for aliases right > now. Even worse, if you do an ALTER PROPERTY to change property name, only > the schema will be affected, but data will remain on the old property name > and will also be copied on the new name, so you will have a duplication of > data. > > Thanks > > Luigi > > 2015-10-29 23:25 GMT+01:00 Harish <[email protected] <javascript:>>: > >> In our application, when we define classes in Orient, we have a choice >> between using an application level id (which doesn't change once assigned) >> and a query friendly label for the class names. The label can change >> several times over the course of the class's lifetime, but the app level id >> never changes. >> >> We'd like to avoid the "alter class old name new" command (or any >> non-trivial schema change operations) since we feel that this is an unsafe >> operation with too many changes at the database level. At the moment, we're >> considering the following solution: >> >> 1) Give the Orient class name a physical name based on the application >> level id (say X). Since the app level id never changes, we never need to >> alter the class name in Orient. >> 2) Now we can query the class in Orient using "select from X" which >> returns all objects of that class. >> 3) Now,clearly, "select from X" is problematic since X has no logical >> meaning as the application id X has no semantics making the query hard to >> understand. >> 4) To workaround 3) above, we plan to set the Orient class shortname to >> the logical name which is semantically meaningful (say Y) >> 5) "select from Y" is now the same as "select from X", but has the >> additional advantage of being user friendly. >> 6) Now, when the logical name of a class changes, we change the Orient >> class alias/shortname. So let's say we now change the alias of the class >> from Y to Z. Changing the alias apparently has minimum physical >> consequences in the Orient database. The only thing that changes is that >> now we can simply do "select from Z" instead of "select from Y" and will be >> equivalent to "select from X". Under the covers, since X never changes, we >> never have to call "alter class X name Y" or "alter class Y name Z" >> >> First question: Is the use of class shortname for the above physical >> versus logical class name separation is a good design choice. >> >> Second question: A related question is if a similar physical versus >> logical name separation can be done at the property name level or is >> something like "ALTER PROPERTY X.p0 NAME p1" the only option for changing >> property names. I did not find any concept of a property name alias similar >> to the class name shortname (alias). Essentially, if a property name alias >> was available, then the same solution I described earlier for classes would >> also work for properties. >> >> -- >> >> --- >> 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 [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
