Generic Object FeaturesΒΆ

There are a number of features that would be appealing to have associated with almost all kinds of database objects/entities in the framework.

However these features could easily “outweight” lightweight object, and so there are issues about the overhead in memory/diskspace/efficiency/cpu.

They are things like:

  • Tracking creation/modification date/time, user.
  • Letting administrators add notes to them.
  • Keeping multiple versions for version comparison/roleback.
  • Allowing tags/keywords to make it easier to search.

Some possible things to consider:

  • We could have all non-trivial framework (database) objects derive from a core class that supported all of these kinds of features.
  • We could have all non-trivial framework (database) objects have a unqiue “core-object” id which we could use as a foreign key and ATTACH such extra data too in separate tables.

I propose that we use a core parent data object class from which all non-trivial mewlo objects are derived, a MewloObject.

The primary purpose of this parent class will be to make it possible for all other objects to “link to” (refer to) MewloObjects of any time, and to some extent is orthogonal to the question of whether in code these objects should all derive from a single parent object.

So for example, a tagging or rating system would attach tags to Mewlo Objects, and could thus be used to add tags to ANY derived object typed (forum posts, comments, users, blogs, etc.).

From a database standpoint, in the very simplest “normalized” form:

  • We could simply have a table MewloObjects with a autoincremented field labeled “id”, and another varchar field for “ObjTypeName”
  • Every other “derived” object (user, group, comment, forum post, blog) would have a field MewloObjectId, so that every such object has a unique MewloObject id.
  • All references to objects will be references in fields named “MewloObjectId” and would link to to things like User.MewloObjectId, Group.MewloObjectId.

An alternative:

  • Every time we would normally refer/link to a target object, we instead refer to a PAIR, a varchar “ObjTypeName” and “LocalObjId”, so that, for example a “tag” might be attached to [“User”,123] or [“BlogPost”,345].
  • This would be more efficient for certain kinds of access, but more complicated for others.
  • A combination (un-normalized) solution would be to use a PAIR that consists of the varchar ObjTypeName and the unique-across-tables “MewloObjectId”. The advantage here might be in terms of querying and indices, since any object we want to query on will have a UNIQUE MewloObjectId, wheras otherwise the LocalObjId is not unique and only the pair is useful as a unique index.

Questions:

  • What are the consequences of needing to constantly refer to an objecttype – what are the consequences to doing joins in this kind of case.
  • If we use a centralized MewloObject table, might we store other info in this central class?
  • What other frameworks use a common parent class? Drupal’s “Node” comes to mind (see here).