Hi there, for once, I am not here with a problem... well not with a problem in my WO application :)
Thing is, I am just implementing model validations, and I would be grateful if anyone of you would check my list below and let me know if you can see any other reasonable validation which I should add to it, to make working with models safer and decrease the probability of potential problems. Or, if you consider one of the checks below stupid :) Any object: - name must be non-empty valid identifier (actually I don't know: _might_ there be eg. an attribute name “123” or even “hi there”? Self-evidently relationship names can't contain dots, far as they could be used for flattening... Anyway I've never seen in any model such an exotic name, and am not willing to allow those in my models :)) Model: no validations I could think of (there are things like unique entity names, but they seemed to be better done entity-level, see below) Entity: - name must be unique in the model group - if the class is a generic one, should be the right one preset for project (could be EOGenericRecord or er.extensions.eof.ERXGenericRecord or project's own, but I believe they should be consistent for a project) - table name must be non-empty and SQL-valid - primary key may not be empty Relationship: - name must be unique amongst all entity properties - join semantic and deletion rule must be either empty, or contain one of the supported names - if flattened -- definition must be valid (ie. all parts proper and existing relationships in appropriate entities which properly chain) -- joins array must be empty -- destination entity must be empty -- if any of the parts is :N, the flattened one must be :N too; if not, must be :1 -- I feel here should be more checks. For one, I don't think PK propagation can be ever valid on a flattened rel (or can it?) Flattened, I think, can never contain another flattened one, or can it? Can you see other validations? - if not flattened -- destination must be a name of an existing entity in model group -- if propagates PK --- there can't be a PK-propagation loop leading to the same entity --- optional warning if not owning (that is valid, but far as I can say, does not make really sense. Or does it?) --- error if the target is not a PK -- if the target entity looks like an M:N intermediate table (generic, all attrs PKs, exactly two :1 relationships) --- warning if the rel is :N (again, I believe this is valid, but does not make sense in any sane model; do I overlook something?) --- if it does not own destination (dtto) --- if it does not propagate PK (dtto) --- if it does not cascade delete (dtto) -- error if there are no joins or invalid join names (for which there is no attribute) -- error if if the source and destination type for joins differ -- error if if the type is BOOLEAN (I believe all other database types can be used for joins, although some, eg. TIMESTAMPs, would be rather unusual) -- optional warning if source attribute of :N is not a PK (valid, but does not make sense in any sane model; do I overlook something?) -- error if target attribute of :1 is not a PK (and also if the joins do not contain a complete target PK) -- warning if the mandatory switch of relationship and the allows null switch of its source attribute do not match -- warning if :1 PK -> PK is not owning or does not cascade delete (again, valid, but nonsense far as I can say) -- error if the deletion rule of an owning relationship is nullify (which makes sense) or cascade (which does not IMHO, but Apple decided so :)) -- warning if the deletion rule is NoAction and there is an inverse relationship Attribute: - name must be unique amongst all entity properties - class name must be non-empty and valid, plus optional check whether it is one of supported class names (NSString, NSNumber, NSDecimalNumber, NSCalendarDate, NSData) - optional check whether the value type is valid for the selected class name - if the attribute is a primary key -- it must have an empty definition -- it must be used for locking -- it may not allow null -- optionally a warning if it is a class property (definitely valid, but indicates a bad design I believe) - if there is no definition at all -- the external type must be nonempty, plus optional check whether it is one of types supported by the database used for the model in the project -- the external type and value type should match the class name -- the column name must be non-empty and valid -- I wonder, should I enforce unique columns? Frankly I do not know whether two attributes addressing both the same DB column even make a valid model or not. - if there is a non-empty definition -- that both external type and column name are empty -- if the non-empty definition does not make a proper flattened attribute (ie. the attr is derived) --- whether the attribute is read-only --- whether it is not used for locking -- if the definition makes a proper flattened attribute (ie. all parts proper and existing relationships in appropriate entities which properly chain, last one an attr) --- all the parts must be :1 (or is it valid to flatten an attribute through an :N?) --- the final attribute itself cannot be flattened (or is it valid to chain flattened ones? What about derived ones?) --- checked and final attribute must have same values of className, valueType, width, allowsNull, readFormat, writeFormat, isReadOnly, precision, scale, serverTimeZone, valueFactoryMethodName, adaptorValueConversionClassName, adaptorValueConversionMethodName, and factoryMethodArgumentType --- readFormat and writeFormat must be empty OK, I could not think of any else validation rule. Have I omitted something of importance? Thanks a lot, OC _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
