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