searching and retrieving object attributes with just one query (SREL,BREL,NREL question)

[alexandre hadjinlian guerra]

Hello

i was able to find that i can do the query below for requests for a given userid, but i was looking for an easier way to find which attributes an object do offer to perform searches. May i ask for more detailed examples and tutorials?   specially explaining what SREL,BREL and NREL means?   string relation?  binary realation?  numeric relation?

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://www.ca.com/UnicenterServicePlus/ServiceDesk">
   <soapenv:Header/>
   <soapenv:Body>
      <ser:doSelect>
         <sid>637507063</sid>
         <objectType>cr</objectType>
         <whereClause>requested_by.userid = 'xxxx'</whereClause>
         <maxRows>1</maxRows>
         <attributes>
            <string>requested_by.userid</string>
         </attributes>
      </ser:doSelect>
   </soapenv:Body>
</soapenv:Envelope>

[Alfie Power]

SREL (String RELation): Represents a relation between two tables in the database where a single record in the first table can relate to only one record in the second table. Usually, it references a unique string identifier. BREL (Binary RELation): Represents a relation between two tables where a single record in the first table can relate to multiple records in the second table. It's a "one-to-many" relationship. NREL (Numeric RELation): This is less common, but it implies a relationship based on numeric fields.  

TellTims

[Marc Horlomus]

hi,

on server side, you can do a command to retrieve object information: bop_sinfo -d <FACTORY>

example:

bop_sinfo -d cr

// domserver: an value attribute named "id" of the factory cr
// db: a column named "id" of the table "call_req"
// takes integer numbers
id                   INTEGER

// takes a string of 30 chars
persistent_id        STRING(30)

// takes a date, which is stored in db in unix time stamp format
open_date            DATE

// takes a duration, which is stored as number of seconds
time_spent_sum       DURATION

// takes a UUID; hexadecimal string
new_affected_resource LOCAL UUID

// takes a non-integer number; never used and somekinda buggy
myStuff              REAL (or DOUBLE...can't remeber)

// LOCAL means this field is generated and filled by the domsrvr, it's not backstored in db
producer_id          LOCAL STRING(20)

// single (?) relation: points to an single objects in a factory
// in this example: affected resource stores the "id" of a record in the factory nr (table ca_owned_resource)
// id's in ca_owned_resource table are UUIDs. so, if you have a look into table call_req on field affect_resource, 
// you will see it's of type UUID (sql says "binary"), too.
// if you query this field, you will get an UUID
// on SRELs you can easy do the "dot.notation": affected_resource.family.sym
//     "affected_resource" points to an "nr" object with an specific "id". 
//     there (in the factory "nr") is an attribute "family" which points to an object of the factory "nrf" 
//     and there is an attribute "sym"
// maybe you wanna see this as a 1:1 Relation
affected_resource    SREL -> nr.id

// back (?) relation: points to a list of objects in a factory
// in this example: all "alg" factory objects where the field "call_req_id" is filled with this ticket id
// so, basically it's the other side of an SREL. from "alg" objects view, call_req_id is an SREL
// BRELs generated by domsrvr, no backstore in db!
// if you query this field, you will get a list of "alg" objects where "call_req_id" points to this ticket
// maybe you wanna see this as a 1:n Relation
alg                  BREL <- alg.call_req_id {call_req_id = ?}

// query (?) relation: points to a list of objects in a factory
// in this example: all "atev" factory objects where the field "obj_id" is filled with this ticket id and "group_name" is SLA
// QRELs generated by domsrvr, no backstore in db!
// if you query this field, you will get a list of "atev" objects where "obj_id" points to this ticket and "group_name" is "SLA"
// maybe you wanna see this as a query-based 1:n Relation
sla_events           QREL <- atev {obj_id = ? AND group_name = 'SLA'}

// link (?) relation: points to a list of objects in a factory
// in this example: there is a factory "lrel_attachments_requests". in this factory there are two attributes, "cr" an "attmnt". 
// the "cr" attribute points to this ticket ({cr = ?})
// the attmnt" attribute points to an "attmnt" object (an attachment)
// from "lrel_attachments_requests" view, "cr" is a SREL to a single ticket and "attmnt" is a SREL to a single attachment
// from view of object "cr" this is a BREL to the SREL in "lrel_attachments_requests"
// in "attmnt" factory there is a BREL like this:      requests             BREL <- lrel_attachments_requests.attmnt (LREL cr) {attmnt = ?}
// to make it more clearly :)
//
// table lrel_attachments_requests:
//
// | id |   cr   |   attmnt   |
// |--------------------------|
// |  1 |    100 |       4711 |
// |  2 |    101 |       4711 |
// |  3 |    102 |       0815 |
// |  4 |    101 |       1000 |
// |  5 |    105 |       1001 |
// | ..............
// ....
// there are relations between:
//   ticket number 100 and attachment number 4711
//   ticket number 101 and attachments number 4711 and 1000
//   ticket number 102 and attachment number 0815
//   ticket number 105 and attachment number 1001
// 
// if you query this attribute on the ticket with id 101, you will get a list of attachments related to this ticket (4711, 1000)
// maybe you wanna see this as a n:m Relation
attachments          BREL <- lrel_attachments_requests.cr (LREL attmnt) {cr = ?}

...and pls don't forget....that's just the "way" my brain "handle" this stuff ;)