So, what's an object attribute anyway?

When is a thing part of an object's state and therefore an attribute, and when is it something else?

Take an object, let's call it a node. Say you occasionally modify these nodes and you want to record the time you've modified them. Is that modification time part of the state of the object or is it a property of the surrounding framework in which the modification was carried out?

And what does 'modified' mean anyway? Is deleting the node a modification? What about changing who has read access to it? Or is that a modification of the authorisation sub-system?

The mind boggles.

Why I've come to meditate on such mind-crushingly philosophical questions is because of the development I've been doing on Everydevel, or should I call it 'Omnia' the web CMS that is/was the basis of perlmonks and several other web sites.

Say that you use this CMS to publish articles on the web. These articles are true gems of insight that add to the sum of human knowledge and benefit the entirety of humanity. Sometimes, however, the articles have errors. You wish to correct these errors and in the interests of full disclosure, you want to publish the times they were modified.

Is that modification time a property of the text of the article, of the html which marks up the article, of the unique URL that points to the article, or something else?

Your articles are represented in perl as objects, i.e. blessed hashes. These inherit from a class of objects called a 'node'. You want to store all these objects persistently, and you choose a relational database to do so. You create a table called 'node', do you have a field called 'modified' to store the time that the 'node' was 'changed'? What if you have thousands of rows in the table and the most common value for the modified field is 'NULL'. Aren't you now breaching First Normal Form? Should you rethink your design?

Instead of having a row called modified, what about another table called, say, 'object_state_changes', that records when the node objects were modified? Or, what about a table called, say, 'significant_dates'? This table would not only list 'modified' dates but also, date of object creation, publication, withdrawal from publication, second publication and so on.

And what does all this mean for the application logic? Irrespective of how you decide to store the the date of modification, should 'node' objects have a 'modified' attribute? Or should that piece of data be accessed as a method of the database interface?

And while we're at it, what is an object attribute anyway?

All this, and all I wanted to do was serve some html.

UPDATE: Thanks all for your replies. Now, I see that for this project the 'modified' attribute is in fact a flag to indicate whether an object is in its initial state and when it was taken out of that initial state. This is different from a date an article was 'published' or 'updated'. I'm going to be tweaking the db design and object model to reflect this.

Comment on So, what's an object attribute anyway?

Replies are listed 'Best First'.
Re: So, what's an object attribute anyway? by moritz (Cardinal) on Jul 22, 2010 at 14:05 UTC
Take an object, let's call it a node. Say you occasionally modify these nodes and you want to record the time you've modified them. Is that modification time part of the state of the object or is it a property of the surrounding framework in which the modification was carried out? An approch would be to do what version control systems like git do: equate a node with a branch in git, and a version of an article with a commit. So in that case each node has an ArticleSnapshot (or whatever name you can come up with), which has an author, timestamp and text body, and is immutable. It has also a pointer to the previous version (or multiple previous versions, if you allow merges). For ease of use, you could add delegation from a node to its current revision/snapshot, and a method that modifies the text, but under the hood it really stores a new snapshot. If the content is stored in a database, you could even do that on the dabase level, with a trigger.	[reply]
Re: So, what's an object attribute anyway? by roboticus (Chancellor) on Jul 22, 2010 at 16:29 UTC
Nomad: As I see it, most of your questions center around two points: metadata and design decisions. When you design an application, you'll have to decide what state information you want to keep about each object. You'll also have some information about the state information (the metadata). In some applications, you'll keep track of the metadata and in others, you won't. These are the choices you'll make as a designer. Many of the specific questions you're asking are for clarifications of definitions--however the definitions are application-dependent as well. For one application, "modified" may mean a change to the values of a node, while for another application "modified" may mean a change to the data and/or metadata. You should be able to resolve many of those questions by clarifying/negotiating the requirements with your users. For example, it may mean that you'll have several "modified" values, one for permissions changes, one for value changes, one for ....etc. ...roboticus	[reply]
Re: So, what's an object attribute anyway? by mertserger (Curate) on Jul 22, 2010 at 14:03 UTC
Nomad Like in all things I guess "there is more than one way to do it" so I am guessing you will get lots of different answers. I work in publishing and content management is really very important in what we do. On the product I help to maintain, we have pieces of text which can be modified in either small or big ways. Every time the text is saved back to the database it creates a record of the fact there have been changes to the text with a timestamp (and other data such as the id of the person who made the change). My viewpoint (coming from an XML background) is that the text is "data" and the other info is "metadata" (data about the data). The text might contain date information in it but this is not the metadata. Data is usually meant to be looked at by humans whereas the metadata is used by scripts, applications, etc.	[reply]
Re: So, what's an object attribute anyway? by wfsp (Abbot) on Jul 22, 2010 at 14:30 UTC
There must be situations where knowing the history of node could be important. Who did what when, why, and how often. A list with one item or many. The severity of the change. Perhaps an attribute of a node would be a history object with its own table. Perhaps the page renderer could include the data at the foot of the page. Think of all the reports you could generate. Perhaps an award for the most badly beaten up, molested article. There are certain monks that would be weighed down with medals if such information was available in the monastery. :-)	[reply]
Re: So, what's an object attribute anyway? by JavaFan (Canon) on Jul 22, 2010 at 17:09 UTC
Your articles are represented in perl as objects, i.e. blessed hashes. These inherit from a class of objects called a 'node'. You want to store all these objects persistently, and you choose a relational database to do so. You create a table called 'node', do you have a field called 'modified' to store the time that the 'node' was 'changed'? What if you have thousands of rows in the table and the most common value for the modified field is 'NULL'. Aren't you now breaching First Normal Form? Should you rethink your design? Well, whether 'NULL' is allowed in 1NF is controversial. The page you link to actually points this out. However, there's no reason you should have NULLs in your database. Given that you chose to use a relation database to store your data, it does not mean any object should map to a single row, using a column for each possible attribute. Such a mapping is of course the most trivial to implement (and often seen), but it doesn't do justice to the relation database, and you aren't likely to end up with a structure that's in any normal form. You may as well use DB_File or YAML to do your persistent storage. But using an appropriate mapper between your objects and your database can give a good database structure. It may mean extra work though.	[reply]
Re^2: So, what's an object attribute anyway? by herveus (Prior) on Jul 23, 2010 at 15:55 UTC
Howdy! ...and the controversy over NULL in 1NF depends on what you mean when you say NULL. If NULL means "this datum is presently undefined", that's one thing (and not necessarily a violation of 1NF). If, on the other hand, it means "this datum does not exist in this tuple" (as in the classic repeating group situation), it's symptomatic of the the basic issue with 1NF. But I digress... yours, Michael	[reply]
Re: So, what's an object attribute anyway? by Anonymous Monk on Jul 22, 2010 at 13:37 UTC
Is that modification time a property of the text of the article, of the html which marks up the article, of the unique URL that points to the article, or something else? Its a property of the text and something else. Part of the text should be the publishing date. If you're adding a little substance, you need to note that in the text, maybe in a footnote, or you re-publish and add a edition/version number alongside the new publishing date. If you're fixing typos/markup, you don't need to update the text, but the last-modified timestamp gets updated.	[reply]


Don't ask to ask, just ask
	PerlMonks