Talk:DVDTrader

CS290F Fall 2006 - UCSB Computer Science - Thorsten von Eicken

Project Comments

This is a fine project idea, but there are a number of technical issues.

1. There's no obvious transactional features here. You need some action (even if it's somewhat contrived) that has atomic semantics with respect to the database. This is needed for parts of project four to be meaningful.
2. The standard practice in Rails is that the primary key of each table is simply named "id". This is just a convention that can be overridden when imlpementing classes, but if you stick with the convention things are much simpler. Similarly, the foreign keys are conventially named as the singular of the foreign table name followed by "_id". For example, a foreign key referencing the "users" table (note that SQL is case insensitive, hence everything appears as lowercase) would be "user_id". Again, you can override this in Rails, but things are going to be a lot more straightforward. Also, the convention has the side effect of making things a lot less cryptic. I know that I personally can understand "rating_id" more easily than "rid".
3. You seem to be not quite getting exactly how models and controllers fit into the MVC model required by Rails. Here's some explanation that is hopefully helpful:
   • Models are the data objects in the web application. You have these basically correct, but see the comments below on database structure. Models correspond in a (nearly) one-to-one fashion with database tables.
   • Controllers are not pages in your web site. The methods of the controllers are the pages in your web site. The controllers typically correspond to the major data Models, but define the business logic of how to present the data to the views, which actually render the web pages themselves. I'll get back to appropriate controllers for your web application after I've discussed the appropriate models and relationships.
4. The database layout needs some tweaking. Users and Dvds are pretty obvious, and are just fine. Collections is a bad name choice, because really, the role of the table is to create associations between Users and Dvds. Each entry in this table, and hence each object it represents, is not a collection, it is not a collection, but rather an association. Sometimes these objects are hard to name. In this case I think something like UserDvd (table name user_dvds) would be more appropriate even if it's a bit awkward. This is also the appropriate place to store a rating (presumably this is just a sort of number. A null entry would indicate an unrated DVD, while a number would store the rating value. The Requests objects are fine and would, as you've indicated have two distinct foreign keys into the users table. Summarizing, you have the following database tables and corresponding data models:
   • table: users; model: User
   • table: dvds; model: Dvd
   • table: user_dvds; model: UserDvd; also stores rating values
   • table requests; model: Request

You may wonder where the object reprenting a collection went. The answer it there are no such objects. A collection is implicitly just the set of DVDs associated with a particular user. It doesn't need an object to represent it. If you want a way to subdivide each users DVDs into collections, there's two approaches: either associate a tag with each UserDvd object ("category"), or—and this is much more flexible—allow users to tag their DVDs with labels they've created. This would require a labels table/model with each label and it's text name (keys by user_id so that you know who's labels are who's). It would also require a dvds_labels join table (this needed by exposed as a data model, but would be used by the has_and_belongs_to_many method). Obviously, the latter approach is much more work.

1. Finally, let's talk about controllers. Given this set of objects, what controllers would you want? Like I said, controllers tend to correspond to the major data models in your application. In this case, you'll probably want the following controllers:
   • user: create, view, edit and delete users accounts (most users can only delete/view/edit themselves)
   • dvd: create, view, edit, and delete DVDs. Unless users can actually modify the collection, this may degenerate to simple viewing DVDs
   • collection: you may want a controller that let's you see your collection or other users' collections and do various things with them. (I guess this is where the collection object went.)
   • request: create, view, edit, and delete DVD requests.

Sorry for the overly long explanation. Please don't be put off by this, I'm just trying to make sure things are clear and that you can get your project working smoothly. Fighting against the MVC model and Rails conventions are going to make your life very difficult. Pleas don't hesitate to email me or let me know if you have any questions. Stop by my office hours too.

Stefan 15:05, 27 October 2006 (PDT)

• I get a redirect to the DVD Trader system, but that never loads. Please fix and email me when ready.
• Critical path SQL analysis missing.

TvE 00:10, 18 November 2006 (PST)

• Works now!
• The next page for searches does not work, always returns empty page even if there are more search results.
• Adding DVDs to my collection is a bit painful: lots of clicks for each one... (Doesn't matter for the course project)
• The string search will not index. You may want to switch to a prefix match for the benchmarking.

TvE 17:18, 19 November 2006 (PST)

I like the new wiki pages!

TvE 17:54, 26 November 2006 (PST)

• Something weird is going on in your performance measurements for project 4a. On the SQL analysis page all the pages take between 1/4 and 1/2 second to complete, with most of the time spent in the database. Then, in project 4a, you show 30-60 replies per second. This is clearly incompatible with the sql analysis timings. You need to double-check that the requests issued are really what you think they are. Check the production log while running the benchmark (you only need a brief run) to verify the URIs and the return codes. You can also use --print-reply with httperf to see the responses (produces lots of stuff).
• Please show the input workload files for httperf, else it's difficult to figure out what you're actually hitting.

TvE 18:18, 2 December 2006 (PST)

• The request rate was something that troubled us as well. The performance logs from production.log (critical path example now on Performance Analysis 4A) had varying request rates. Pages with no database query would typically have respose times on the order of 100ths of seconds, while pages that performed database queries (like dvd list and search) took 10ths of a second. We figured that the response time returned by httperf would be the average of these over-all. Perhaps we were mistaken?
• The input workload files are now on the Performance Analysis 4A page.

wileym66 12:04, 3 December 2006 (PST)

• The response time and reply rates reported by httperf are averaged, that's fine. I'm pointing out that the response times you reported are incompatible with the rates you reported. Also, make sure you report the reply rate and not the request rate!

TvE 14:34, 3 December 2006 (PST)