A wiki page may have a number of revisions, so we'll model it with two classes: Page and Revision.

Please discuss the pros and cons of the following design decisions:

1. (10pt) Bidirectional association vs. unidirectional association between Page and Revision.

2. (10pt) Implementing the Subscribable interface vs. keeping Set<User> subscribers in Page.

3. (10pt) Keeping file attachments (i.e. Set<File> attachments) in Page vs. keeping them in Revision.

Whoever gives the best answer to a question receives the credit for that question, which will be added to their HW3 grade.

2. I have used Set<User> for subscribers because I want to make it simple and less confusing.

3. I would go with wikiRevision because each Revision can have different attached files. Like in initial revision user may not have any attachment but later he/her can add it. So, each revision should have its attachment files.

1. Bidirectional association would be better choice if there is a large number of pages with each page having minimal number of revisions. Bidirectional association makes the object access from the other class easier/faster.

But this also means there is an overhead to keep objects in both the classes (hence minimal number of revisions - which is usually the case). 

3. Keeping file attachments in Revision is easier of the design choices as different versions of the same file does not have to be maintained.

Different revisions may have different file attachments (or different versions of the same file).  Keeping file attachments in Revision lets us achieve this.  There is an overhead of keeping unchanged attachments between versions.

3. Keeping file attachments (i.e. Set<File> attachments) in revision is a better option because when we revert pages to particular revision we able to provide correct attachment information about the revision.

For example: if revision 1 have one attachment (A) and revision 2 have 2 attachments (A and B) and when we revert page to revision 1 then we will able to display correct attachment of revision 1(i.e. A).

If we keep file attachment in page then we will lose the revision information for attachments.

3) Implementing the Subscribable interface vs. keeping Set<User>  subscribers in Page.

Pros: By Implementing the interface, the user object and the subscribable object can be passed to the subsription table ,
since the subscription table has the users, we can get the users from it and user object would give us user's details like email id

Cons:Design becomes complicated

Pros : keeping Set<User> subscribers in Page, we can query all users who subscribed for a particular wiki page and viseversa. This keeps the design simple

 Bidirectional association vs. unidirectional association between Page  and Revision.
 Bidirectional association between the Page(one to many) and Revision(many to one) is complex and involves the use of joins. Unidirectional association makes simpler designa nad mapping.
 
2.Implementing the Subscribable interface vs. keeping Set<User>  subscribers in Page.
Implementing the Subscribable interface, we need to implement all the abstract methods of interface. and using the Set<User> subscribers in page we can get the required properties like name and email of the user.

3.Keeping file attachments (i.e. Set<File> attachments) in Page vs. keeping them in Revision.

Each file attachment is considered a new one. hence it is easy to map attachment with a revision rather than a page.
 

2. Implementing the Subscribable interface ensures that the methods for implementing subscription of  Page/Topic/Mailinglist  are the same (we can reuse the code). This makes it easier to maintain and add new features (eg: Daily digest or Weekly digest modes of subscription). Database mappings has to be done carefully.

Keeping file attachments (i.e. Set<File> attachments) in Page vs. keeping them in Revision.

Keeping file attachments (i.e. Set<File> attachments) in Page- this will have the attachements at the page level, which is not the requirement


keeping them in Revision.- Adding attachment is also a kind of change done to the revision which will be treated as a new revision , so file attachments should be in Revision .Retrieving a particular attachment of a particular revision from revision page will be easier to mantain

1. Bidirectional vs. Unidirectional association between Page and Revision:

Unidirectional Association: Less complex but more tedious to maintain the relationships while editing. In the current example we may never want to go backwards i.e. from revision to the main page hence works better.

Eg. the Page class{page_id(pk), title,..} and Revision class {revision_id(pk), page_id(fk), revision}. 

Lets say we have unidirectional mapping as Set<Revision> revisions in Page class. If we try to insert a new revision into the database. the sql queries will be something like: 

insert into revisions(revision) values(?)
update revisions set page_id=? where revision_id=?

Bidirectional:

Bidirectional association makes changes made at one end visible to both the ends/parties which makes it easier to maintain database and write queries but not the best choice to our needs for this scenario.

Eg.: we use Set <Revision> revisions in Page class and many-to-one mapping with Page in Revision. If we try same insert again, then:

insert into revisions(revision,page_id) values(?, ?). 

Only one sql statement manages to insert the statement and maintain the relationship.

2. Implementing Subscribable interface provides more flexibility to change(more methods) the subscription policy for the page in future to owner and subscription options to users.

While keeping set<users> as subscriber in page allows more flexible access and maintenance.

3. Keeping file attachments (i.e. Set<File> attachments) in Page vs. keeping them in Revision.

Attachment sems to be associated with each revision hence must be maintained with the Revision. Different revisions of the same page could have different attachments.

However if we have attachment as a property of page then several revisions could share the same file as attachment and have their own individually if required.

1.
Bidirectional association
Pros: easy access to revisions from page and vice versa.
Cons: increase of redundancy
Unidirectional association
Pros: easier to implement; reducing redundancy.
Cons: complex queries for retrieving Page information from its Revision.

2.
Implementing the Subscribable interface
Pros: Implementing the Subscribable interface is preferable from the point of using same way of subscribing to different services provided by the project.
Cons: Retrieving subscribers for particular page would be more complicated
Keeping Set<User> subscribers in Page
Pros: more "object-oriented" approach
Cons: increases redundancy.

3.
Keeping attachments in Page
Pros: Simpler files hierarchy. When the user sets the password on some page, this security would be inherited by all page attachments.
Cons: attached files may have own version (like the libraries in the Eclipse project could be version controlled)
Keeping attachments in Revision
Pros: possibility to track not (missed in original post) only changes in content of the page, but the versions of attachments as well.
Cons: security control for attachments became more complicated.

1. Bidirectional association between Page and Revision:

Pros: Bidirectional association increases the interdependency between Page and Revision, i.e any changes made to the Page class will be reflected on the Revision class too. This model works good for our application as there are setter methods(like setting the author of a revision)  in Revision class  which may seem like independent functions of the Revision class but these changes have to be reflected on the respective Page object. It reduces the size of SQL queries and gives a better performance.

Cons: It increases the size and complexity of our code. We have to be careful when the Page and Revision objects are created or removed. For instance, if you delete a Page object, it is likely that the Revision object still remains. For our wiki application, it would make no meaning to store Revisions when it doesn't have a reference to a Page object.

Unidirectional association between Page and Revision:

Pros: There's a looser coupling between the Page and Revision. Almost every function in the Revision class can be accessed through a Page object. It also makes sense to think that Revisions can not exist without a Page. Reduces the size and complexity of our code.

Cons: If I insert a record into the Revision table I need to write a SQL query that takes care of both inserting data into the Revision table as well as making the reference to its corresponding Page table record as opposed to single SQL statement that can take care of both inserting data and maintaining relationship in bidirectional mapping. This clearly reduces the performance.

2. Implementing the Subscribable interface in Page:

Pros: Subscribable interface is more generic as opposed to having it as a property in the Page class. This makes it more flexible for future changes or reuse of code in our application. It is possible that we could have a new requirement in the wiki application which requires us to provide subscription for it. In such instances the new class has to just implement Subscribable interface unlike having to create a new property in the new class to store the set of users. Secondly, we might need the data of all subscriptions used in CSNS, that is not just the subscriptions for a Page which is made easy with Subscribable interface. This also reduces the necessity of creating new tables for every type of subscription.

Cons: We will have to override all the methods of the Subscribable interface in Page.

Keeping Set<User> subscribers in Page:

Pros: It is easier and faster when it comes to accessing the subscribers of a Page.

Cons: It reduces the scope of reusability and changes we could make in our application.

3. Keeping Set<File> attachments in Page:

Pros: It obviously reduces the complexity of mapping and retrieving the files associated to a Page.

Cons: Revisions are created every time there is a change in the content of a Page. Some files could be associated to a particular content spoken in a newer revision of a Page. So if I were to revert back to an older revision then I should only have the files associated to that particular revision. It makes it difficult to associate files of a particular revision by keeping Set<File> attachments in Page even though it is possible as most likely the owner of a file could be the author of the revision associated.

Keeping Set<File> attachments in Revision:

Pros: Its easier to map the association between files and revision as files are rightly associated to a revision content over a page content.

Cons: To retrieve files associated to a Page requires us to traverse through each and every revision associated to that Page.

 1)Pros of Bidirectional Mapping: 

cysun wrote:

A wiki page may have a number of revisions, so we'll model it with two classes: Page and Revision.

Please discuss the pros and cons of the following design decisions:

1. (10pt) Bidirectional association vs. unidirectional association between Page and Revision.

2. (10pt) Implementing the Subscribable interface vs. keeping Set<User> subscribers in Page.

3. (10pt) Keeping file attachments (i.e. Set<File> attachments) in Page vs. keeping them in Revision.

Whoever gives the best answer to a question receives the credit for that question, which will be added to their HW3 grade.

ANS. : 1 

It is easier to retrieve revision detail from page as well as from revision we'll find the page detail.

as we have seen in class the example of account and customer and discuss about unidirectional and bidirectional design of data.

In our case its easy to retrieve both class detail in bidirectional.

ANS.:2

In our csns project "Subscribable interface" is useful in "forum" , survey and our wiki. We just implement our interface for subscribe or unsubscribe. .

Like in table definition we put from which we get subscribe? eg.: if it is from wiki then we put "wiki", if it is from forum we put "forum" and so on....

so, using that interface we are designing such a database which have NO Redundancy and we can manage the subscriber of forum, survey and wiki in one table and same way  unsubscribe it also.

So, rather than having redundancy in database we have good design .

So, I think it's good to use interface than set<user>.

ANS.: 3

I think it's better to have keep tracking of files in REVISION so, one can change it and and we can save it there. and finally we can retrieve it and display it easily.

1.Bidirectional association is convinient to write a code to get reference
for both side between Page and Revision. Database has all information you need.
Unidirectional association is not efficient sometimes by keeping all in your application memory.
You need to write a query to get some information.


2.Keeping Set<User> subscriber in Page is easy to access by getting all properties.
Nevertheless, Implementing the Subscribable is recommended.
It is more efficient in order to save the object in a binary form using the input output stream.
It doesn't have to go back to database to retrieve all properties. you can just inherit properties required.

 

1. (10pt) Bidirectional association vs. unidirectional association between Page and Revision.

 Bidirectional association:
PRO
- It would have direct relationship when searching for revisions having a page. As well as it
 would have direct association also when looking for a page having its revision number.
- Simple queries to display information because is mapped on both associations.
CON
- Hard to maintain tables and relationships
- Demanding more computer resources in case of large sets of information

And the winners are:

1. none

2. alomo, dfostersmith, rahulajit: +5

3. hareshdhola, Pallavi0205, prajaktas, sunitha, praticsula, sunaina, rahulajit, CS320stu08, cs422@2009, prenteria: +10

And some general comments:

• The question asks for pros and cons, not which one is better or preferable, so you need to discuss both sides.
• Understanding something doesn't mean you can explain it clearly and correctly.
• There seems to be lots of misconception about object and object reference. We need discuss this in class.