Attributes describes the content of an entity. An entity has one or more attributes that represent how this entity should store and present itself to clients. Attributes are implemented as columns in the database but an attribute can also be derived from another entity. Each attribute can have its own properties and also its own code generation properties, which will determine how the code is generated and the code generation template is applied.
Types of attributes
Attribute(s) inherited from a parent entity that are part of the entity key.
Attribute(s) that are part of the entity key.
The parent key and key attributes together describe the primary key (PK) of the entity. The primary key must uniquely identify the entity.
Public attributes are attributes that are visible to other entities within IFS Applications. One example is if you have a reference between two entities, you are allowed to fetch the description of the referenced attribute. This is done by following the reference through the foreign keys and then fetching the correct description. The description used must be a public attribute in order to be fetched.
Private attributes are not visible outside the entity itself. So another entity is not allowed to get a private attribute through a reference even though it is possible. Private attributes should not be considered secure, in such ways that they can't be retrieved by any client. This is not the purpose. The purpose of private attributes is that they are supposed to describe something that is only of interest to the entity itself.
In IFS Cloud there are a few system attributes that are added to any entity, some of these are always mandatory whilst others could be non mandatory dependent of property of the entity. These system attributes are described below.
Objid represents the direct address to the object, this is the fastest access to a specific row within an entity. In the database objid is represented as a virtual column called ROWID which is a file pointer on the file-system to the row. Clients must know about the objid since they fetch the objid, objversion upon retrieval of the specific row of the entity. Objid is used in client interfaces to point to the correct row in a specific entity. Server to server calls operates on the Primary Key (PK) or the alternate key (AK) objkey. Objid is not allowed to use as a persistence field, the reason for that is that the value of objid will change if you move database values to another database.
Objversion stores the version of the row that is retained for usage. Objversion is used as the locking mechanism in order to know whether a client is working with the correct version of the row or not. If a client has retrieved an "older" objversion than what is currently stored in the database, you are not allowed to continue with your transaction.
This attribute is only added to the entity if the entity has a state machine. This attribute holds the state of the entity, at one specific moment. This attribute changes value if the state machine is invoked in a correct way.
This is an alternative key (AK) for the entity. So the entity row can be represented by storing the objkey. This attribute can be used when you want to have references from many different entities to one entity. If, for example there is an entity called Notes and that all entities in the system can have a note. Then we can store the Objkey and the entity name to be able to know the reference from the Note to the correct row.
Objtype is only added to your entity if your entity has a generalization type. Objtype shows which type of entity this row belongs to. Generalization is a specialized version of an entity.
TextId$ is the key for Search Domain documents. The TextId$ is an alternative key that uniquely points out documents that should be indexed for free text search by Oracle Text. There must exist one TextId$ column per index. To be able to have two or more Text indexes on one entity it should be possible to have a different name on your TextId$ column, like TextId2$.
Derived attributes are attributes that are not usually found within the entity where they are described. These attributes are derived from another entity but are shown in this entity because they are relevant to this entity. A common example of a derived attribute is the description of a foreign key, e.g. customer name for a customer.
All attributes have properties assigned to them. These properties are used under code generation to generate code that supports the different properties you set on the attribute. As it stands during early 2015 there are five mandatory properties for an attribute.
You can also set code generation properties on an attribute. The code generation properties are used to change how the implementation code is generated.
All entities must have a Primary key. The primary key consists of one or more attributes of the type parent key or key. The key must uniquely identify a record in one entity.
All attributes must have a name. Attribute names are written in camel case in the model and converted to database names.
Example: If the attribute name is LanguageCode, then the database name is LANGUAGE_CODE.
All attributes must have one data type. Some of the data types can have a format, the format is usually optional.
Deprecated data type. Use Text instead.
The data type binary can store digital files from photos, documents, graphics, films, sounds or any binary data in specific formats. The binary data type is stored as a Binary Large OBject (BLOB) in the database.
This is a data type that represents a Boolean value. You need to specify your true and false values in the definition. If using text values the data type in the database will be VARCHAR2, if using number representation the data type will be NUMBER. The length of the VARCHAR2 depends on the length of the texts used for the representation of true and false. Checks are performed in the server code that a correct value has been entered.
BOOLEAN("TRUE", "FALSE") or BOOLEAN("1", "0")
This is a data type that only holds information about a specific day, no time should be considered. This data type is represented as a date in the database where only the day part is considered. This is commonly used by using the Oracle function Trunc which sets the time part to 00:00.0.
Used to reference a predefined Enumeration as the data type.
Unique number generated per row in the database. All of the the implementation is handled by Oracle.
An integer number (which can't have any decimals).
Normally not used, use number instead.
The data type long_text can store texts longer than 4000 Bytes. The long_text data type is stored as a Character Large OBject (CLOB) in the database.
Database lookup with value and description.
This data type should be used for numerical representation. You can add both precision and scale. This is represented as a number in the database.
Text is used for any alphanumeric attributes. The length of the attribute needs to be specified for the maximum width of the attribute. This data type is represented as VARCHAR2 column in the database.
This data type should be used if you only need time for an attribute. This is represented as a date column in the database.
This data type should be used if you need date and time for an attribute. This is represented as a date column in the database.
The attribute flags describes the attribute properties, but also it gives the generated code different behavior dependent of which property that is set. Some examples:
A parent key, key or mandatory property gives a not null constraint on the table that is generated. It also gives code checks in the business logic that these fields must have a value when entered in the system.
An attribute could be protected from updating once it set.
The attribute flags is position based and their meanings are described below:
|Attribute Type||Mandatory||Insert Allowed||Update Allowed||List of Value (LOV)|
|P = Parent Key
K = Key
A = Attribute, Public or Private
|M = Mandatory
- = Not Mandatory
|I = Insert Allowed
- = Insert Not Allowed
|U = Update Allowed
N = Update Allowed if value is null
|L = Attribute included in LOV
- = Attribute not included in LOV
The attribute type determines which type of attribute we want to have. Parent keys and key generates a primary key constraint on the table. This ensures that the primary key is a unique value. A public attribute generates a public Get-method and is included in the public record of the entity. A private attribute does not generate a public Get-method.
This attribute determines if an attribute must have a value or not. If mandatory then the attribute will get a not null constraint and a check in Check_Common___.
This attribute determines if you are allowed to insert a value in an attribute or not. This means that the client/user can’t put a value to the column. The system automatically generates and puts a value in it instead. If insert not allowed, checks for this is performed in Check_Insert___,
This attribute determines if you are allowed to update an attribute or not. If update not allowed, checks for this is performed in Check_Update___,
List of Values (LOV)
This setting determines if an attribute is shown when the client shows a LOV window or not. This setting has no impact on the server code.
The following flags on an attribute means that it is an attribute, which is mandatory, both insert and update is allowed and the attribute is included in LOV.