Critics and Migrator hard to solve

Did you forget some videos or did I miss materials? The tickets about Critics and Migrator felt very hard and I almost gave up solving them. Writing a new codec on the fly and updating Attribute types came out of nowhere to me.

After even thorough searches I did not encounter any hints how to tackle those 2. And the TODOs in the Java code were confusing and not helping.

Please do review these tickets or tell me what materials I missed.

I do not recall have to write a codec for any the labs.

The TODO for Critics is:

// TODO> Ticket: User Report - execute a command that returns the
// list of 20 users, group by number of comments. Don't forget,
// this report is expected to be produced with an high durability
// guarantee for the returned documents. Once a commenter is in the
// top 20 of users, they become a Critic, so mostActive is composed of
// Critic objects.
  1. The array mostActive was already declared.
  2. The class Critic (the codec I guess) was already written as mflix.api.models.Critic;
  3. Return a list of 20 implies $limit.
  4. Return a top list implies $sort.
  5. Number of comments implies $count.

As for the migration, updating an attribute is the same as setting a value.

Could you be more specific about the TODO being confusing? Just saying it is confusing does not help the course writer to improve the content.

Are we really talking about the same class? Of course you have to project the count into a new Class, the critic class.

A Codec is not a data container class like User or Critic (“Coder-Decoder”), a codec decodes that creates the Critic object from the Json. You have to declare the critic codec in the users-dto. Yet there is no word about it in the class or todo.

With the count pipeline you construct a new Json with id,numVotes. This information would help a lot. The new Json is not a User Class anymore.

Instead, the todo says one should retrieve the top 20 ‘Users’, which is misleading. Just saying I solved it that way but it was not as elegant as the real solution.

Regarding the migrations, sure, it is in fact an update. But I needed stackoverflow for solving that one and it took me at least 1 hour and two resets of the db.

There we’re too many places you had to introduce changes, not all had a todo there and most changes (update model) were never discussed.

With the migration you only had one chance - with no test upfront making sure the migration code is correct. The test just made sure the database was correct. So it was a “my dB is garbage now”
Or “yay you’ve guessed the right solution”.

So it would be good if the class description or todos would better describe what techniques one should use and the test should be testing the migration code, not just the outcome.

Hi @syn666

Thanks for your feedback, it appears we should clarify some of this material. Firstly, you do not need to write any codecs for these labs. The existing files for the course that need to be modified clearly signpost with TODO comments where and what should be added. We strive to make it clear and understandable as to where you need to change the code and what the code changes should do without directly providing the answer. There is obviously a balance between providing signposts to which techniques you should use and giving too much detail. I’m sorry it appears in this case it wasn’t clearer.

We appreciate this feedback and as you progress through the course and indeed any of our other courses, please do take the time and effort to continue to give us feedback. This will help us improve the content and courses going forward.

Kindest regards,

1 Like