I'm sorry I was wrong!

Riccardo


2014-04-16 18:06 GMT+02:00 Alan Miller <[email protected]>:

> But https://github.com/orientechnologies/orientdb/wiki/SQL-Alter-Class
> says you can alter the classes name.
>
> I was able to do this in the console.sh
>
>  create class Cust1Page extends V;
>  create class Cust1Page_new extends V;
>
> create vertex Cust1Page set name =  "page1", ver="0.0";
> create vertex Cust1Page_new set name =  "page1", ver="1.0";
>
> orientdb {cust_data}> classes
>
> CLASSES:
>
> ----------------------------------------------+------------------------------------+------------+----------------+
>  NAME                                         | SUPERCLASS
>         | CLUSTERS   | RECORDS        |
>
> ----------------------------------------------+------------------------------------+------------+----------------+
>  Cust1Page                                    | V
>          | 13         |              2 |
>  Cust1Page_new                                | V
>          | 14         |              2 |
> .....
>
> orientdb {cust_data}> select * from Cust1Page;
>
> ----+-----+-----+----
> #   |@RID |name |ver
> ----+-----+-----+----
> 0   |#13:0|page1|0.0
> ----+-----+-----+----
>
> orientdb {cust_data}> select  from Cust1Page_new;
>
> ----+-----+-----+----
> #   |@RID |name |ver
> ----+-----+-----+----
> 0   |#14:0|page1|1.0
> ----+-----+-----+----
>
> Then I dropped the old and renamed the new class.
>   drop class Cust1Page;
>   alter class Cust1Page_new name Cust1Page
>
> Alan
>
> On Wednesday, April 16, 2014 7:59:34 AM UTC-7, Riccardo Tasso wrote:
>
>> If I remember well you can't rename a class, nor move a vertex/document
>> from a class to another!
>>
>> Riccardo
>>
>>
>> 2014-04-16 16:31 GMT+02:00 Alan Miller <[email protected]>:
>>
>> Thanks Riccardo,
>>>
>>> That sounds good. Then I can have one global graph and my web frontend
>>> (servlet) can be simplified and take advantage of the connection pool.
>>>
>>> One question on updating this global graph.
>>>
>>> To simplify things we are re-creating each customer's graph from scratch
>>> daily
>>> (OrientGraphNoTx ... declareIntent(new OMassiveInsert())
>>> instead of detecting & applying differences. The new graph name is
>>> something
>>> like custx_<uuid>. When finished we update some reference table that maps
>>> each customer to their current graph, then drop the old graph.
>>>
>>> In the proposed scenario, with a global graph and different class per
>>> customer,
>>> would I create new class each time I import new data for customerX, then
>>> delete
>>> the records with the old class, and rename the new class?
>>>
>>> for example:
>>>
>>> If my global graph was called cust_data and my Vertex classes were
>>> called Cust1Page, Cust2Page,...
>>> When import new data for Cust1 I would
>>> 1. create class Cust1Page_new extends V
>>> 2. import Cust1 data creating vertices of type Cust1Page_new
>>> 3. delete from cluster:Cust1Page;
>>> 4. alter class Cust1Page_new  Cust1Page
>>>
>>> Alan
>>>
>>>
>>> On Wednesday, April 16, 2014 12:10:47 AM UTC-7, Riccardo Tasso wrote:
>>>
>>>> Probably a good way to model your scenario is to subclass the V class.
>>>> You can create one schema for the V class (author, lastmod, size,
>>>> properties, ...) and then one class for each customer (Customer1
>>>> extends V, Customer2 extends V, ..., Customer3000 extends V).
>>>>
>>>> Advantages:
>>>>
>>>>    - every subclass will inherit the parent schema
>>>>    - it should be faster iterate over all the edges of only one
>>>>    subclass ("SELECT FROM CustomerN ..."), or in general perform any kind 
>>>> of
>>>>    operation shoul be less complex
>>>>    - you can work at global level, if you want ("SELECT FROM V ...")
>>>>
>>>> I know that this seems not the answer to your question. Anyway I think
>>>> that you will have benefits with a multi-class model, especially if each
>>>> customer will access more frequently his own partion.
>>>>
>>>> Cheers,
>>>>    Riccardo
>>>>
>>>>
>>>> 2014-04-15 23:54 GMT+02:00 Alan Miller <[email protected]>:
>>>>
>>>>> Hi,
>>>>>
>>>>> Is it possible to use a connection pool with a partitioned graph?
>>>>>
>>>>>  Consider this:
>>>>> Let's say I wanted to model the contents of 3000 websites in a single
>>>>> graph.
>>>>> The Vertex class in the graph might be called: "Page" with author,
>>>>> lastmod, size, properties.
>>>>> The Edge class might be called "LINKSTO"  (e.g. 0:many (Page --
>>>>> LINKSTO --> Page) relationship.
>>>>>
>>>>> Since each website is a separate customer, I wanted to avoid having
>>>>> 3000 graphs
>>>>> and use a Partitioned-Graph.  https://github.com/orientechn
>>>>> ologies/orientdb/wiki/Partitioned-Graphs
>>>>>  So I'd have one graph for all 3000 customers but 3000 customerid (or
>>>>> graph user).
>>>>>
>>>>> Although I anticipate my site to be low traffic (at any given time <
>>>>> 100 customers)
>>>>> how can I effectively use the connection pool?
>>>>>
>>>>> The connection pool works at the DB level right? Do I need a separate
>>>>> pool for every customer?
>>>>>
>>>>> Per the wiki
>>>>>
>>>>> database = new ODatabaseDocumentTx("remote:localhost/demo");
>>>>>     database.setProperty("minPool", 2);
>>>>>     database.setProperty("maxPool", 5);
>>>>>
>>>>>     database.open("admin", "admin");
>>>>>
>>>>> Alan
>>>>>
>>>>> --
>>>>>
>>>>> ---
>>>>> 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.
>>>>>
>>>>
>>>>  --
>>>
>>> ---
>>> 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.
>>>
>>
>>  --
>
> ---
> 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.
>

-- 

--- 
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.

Reply via email to