Terfin / pyodata-old

An OData framework for Python. It will include a full (as much as possible) implementation of the OData Protocol v4.0
MIT License
0 stars 0 forks source link

Feature Design #4

Open Terfin opened 10 years ago

Terfin commented 10 years ago

Alright, dump your design plans here. Please detail as much as possible what do you suggest and if possible, also attach a diagram.

Terfin commented 10 years ago

Alright, here is the first design diagram. It is a direct translation of OData EDM as written in the protocol itself, no tricks included.

edm

Explanation:

Type - This represents a type of a property. It can be String, Boolean, Number, etc. It can only represent primitive types. Each type will have a relevant set of properties. (In example, a number would have precision, min value, max value. A string on the other hand, would have min length, max length and encoding)

ComplexType - Just as it sounds, a complex, non-primitive type. It is composed of one or more properties, each could be either a Type, a ComplexType or an EnumType.

Entity Type - This represents the Entity Type idea. It could be a Cat class or a House class as well, but for the sake of abstraction, I will keep at generalized. Now if you think of it, Entity Type and ComplexType share the multiple properties concept, thus, if you take a complex type, add a unique key, add relationships support (navigation properties) and annotations, you get an entity type. Thus, Entity type should inherit from ComplexType.

Entity Type 2 inherits from Entity Type, which the single inheritance model. We don't want to try our luck with multiple inheritance just now, not before we get a version of this working.

Entity Type 3 inherits from Entity Type 2, and on and on up to Entity Type N which obviously would inherit from Entity Type N-1.

EnumType - Just as it sounds, an enum. In example Color. Color.Green, Color.Blue, etc.

Annotation - This is a nice feature of the EDM, it lets you add additional let's call it, mini-properties. Annotations cannot be used as operation parameters, nor do they support complex types or enums as their direct values, but they could help to add additional metadata regarding the type or expose mutated values of existing properties according to a certain expression. In example, let's say that my entity has a feature "BirthDate" and I want to return the age, in addition to the BirthDate, I can work this out through an expression and use an annotation to expose it. Also, let's say I want to express the total size of the entity, a metadata property, I can use annotations to achieve that. Each entity has a collection of attached annotations.

Terfin commented 10 years ago

After taking a closer look at the EDM regarding both Atom and Json, I conclude that the design is almost right. The chosen implementation for types is through a set of metaclasses that group types together (In example WholeNumbers for Int16/32/64 and Sbyte), all which will inherit from a root metaclass. In addition, a root EDMType class will hold most of the instance logic, while the metaclasses will hold stuff like creating constants depending on the certain type's intended functionality. In example, we know that Int16 cannot be bigger than 215 and cannot be smaller than -215, thus we have a predefined domain of accepted values, once the type is used to "in action".

Features are being designed further during development. This is going into the implementation stage.

Terfin commented 10 years ago

Implementation continues, EDM types development was put on hold in order to put some effort into the metadata document. Still under the EDM branch.