2.3.3 Attribute

An attribute can be either a class field (and a database column), or simply just a database column.

You cannot have two attributes with the same name inside a single entity, but two entities can have distinct attributes with the same name. Similarly, you cannot have two attributes, two relationships or an attribute and a relationship that have the same name within the same entity, but it is okay if they each live in a different entity.

An attribute may have the following properties:

name:

the name of the attribute

type:

this is the associated python type, which can be either string, int^2.3 float or DateTime (mapping to egenix's mxDateTime -or to DCOracle2.Timestamp). You should keep the externalType (described below) and the python type in sync (python string: SQL CHAR, VARCHAR or TEXT^2.4, int: SQL INTEGER, etc.).

isClassProperty:

indicates whether the Attribute correspond to a class' attribute. An example would be an id column serving as the primary key.

isRequired:

indicates whether the attribute is mandatory, i.e. if it can have a value of None. If checked, this will be enforced both by the validation mechanism included in the framework AND by the database since the corresponding attribute will be created with a SQL statement indicating

NOT
        NULL

columnName

the name of the column in the entity's DB table

externalType:

the SQL type to which this attribute should be mapped. The supported SQL datatypes depend on the adaptor, please refer to their documentation for details:

MySQL: MySQLAdaptorLayer
Oracle: OracleAdaptorLayer
PostgresqlSQL: PostgresqlAdaptorLayer
SQLite: SQLiteAdaptorLayer

precision, scale, width:

depending on the externalType, you may have to specify one or more of these elements to fully define the SQL datatype. Refer to any SQL reference manual for details (Postgresql 7.3 devel. documentation, chapter3: Data types is a good starting point).

Note: The field width is used at runtime when validating a string attribute's value (see 3.3, ``Validation''), before objects are saved in the database. SQL data types CHAR and VARCHAR require that width is specified; on the other hand, TEXT -when supported by the database- does not accept that width is set. If you set it on an attribute, it will be ignored when the database schema is generated (i.e. a TEXT field my_text with width=30 won't be declared as TEXT(30), but simply as TEXT), but it will be checked at runtime and validation for this attribute will fail if its value's length exceeds the given width. Note that the same goal can be achieved by writing a specific validation method for the attribute (see 3.3.2).

defaultValue:

use this field to assign a default value to the class' attribute. Note that this is only used when python code is generated from a model. You enter it as a string, it will be converted to the correct type when the model is loaded.

Conversion details: an empty string converts to integer:0, float: 0.0, string: ''; special string value 'None' evaluates to None for type string, and is invalid otherwise.

displayLabel:

not used by the framework, but you can consider it valuable to fill it in and use it in your own applications (see also section 7 describing how a model can be introspected).

comment:

a comment, for maintainers of the model.

usedForLocking:

Unused yet, reserved field.

This flag will be used when optimistic locking is implemented. It will indicate which attributes optimistic locking should check when it is about to save changes: if value for attribute lastname has changed and usedForLocking is set for that attribute, then under the optimistic locking policy saveChanges() will raise; if the flag is unset, the attribute will be silently overriden (for example, you probably won't mark an object's timestamp as used for locking).

Footnotes

...int ^2.3

Note that python types int and long int are treated the same way. This is due to different DB-adaptors having different behaviours -some can also have a ''non-deterministic'' behaviour: sometimes returning int, sometimes long int, for the same db-field and the same value (e.g. 42); anyway it sounds reasonable to consider int and long int as equivalent within the framework's core.

...TEXT ^2.4

if you db-server supports TEXT

Subsections