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:
DateTime(mapping to egenix's mxDateTime -or to DCOracle2.Timestamp). You should keep the
externalType(described below) and the python type in sync (python
idcolumn serving as the primary key.
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).
widthis used at runtime when validating a string attribute's value (see 3.3, ``Validation''), before objects are saved in the database. SQL data types
widthis 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
TEXTfield 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).
Conversion details: an empty string converts to integer:
''; special string value
'None' evaluates to
None for type string, and is invalid
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).
long intare treated the same way. This is due to different DB-adaptors having different behaviours -some can also have a ''non-deterministic'' behaviour: sometimes returning
long int, for the same db-field and the same value (e.g. 42); anyway it sounds reasonable to consider
long intas equivalent within the framework's core.