Chapter 3 Lab 1 Apply the attribute pattern

[David_Thompson]

I need some clarification as to how this works… According to the lab, I am modifying the Events Array to a key value pair. I am also accounting for the date the piece was acquired.

Where I am confused is the original schema has the event as a name and date pair. So… logically this would be kept in the key value pairing right?

The answer that validates is the following code

“events”: [

{ "k":"<string>", "v": "<date>"},

{ "k":"<string>", "v": "<date>"}

]

}

While I understand this, where I am confused is that I am also supposed to account for the acquisition date… Logically wouldn’t this be a different date than the event date? If so… Wouldn’t you need another key value pair to account for the acquisition date?

so it would be

“events”: [
{ “k”: “” , “v”: “”, “date_acquisition”: “”}
{ “k”: “” , “v”: “”, “date_acquisition”: “”}

This would allow for the event name to be searched, the date of the event, and the acquisition date like the lab asks for right? There should be two dates indexed… One for the event, and one for the date the item was acquisitioned.

Thoughts?

lab directions are written so you would think you need two dates for each event.

• use a single index on all event dates.
• transform the field that tracks the date when a piece was acquired, date_acquisition, so that it is also indexed with the values above.

Instead of the key “date_acquisitioned” you can also write is as just “a”: “”

[Eoin_Brazil]

Hi @David_Thompson,

Thanks for your question, by breaking up the original schema into a name and a data pair. We can simply add the details int the acquisition field into this format, where “k”:“acquisition_date” and “v”:"" is used alongside the venues as a key. This allows us to use non-deterministic naming. In this lab and document example, all of the dates are now values in a key pairing. As we have moved to a non-deterministic naming (moving the event location field and the acquisitions field both into values rather than keys) we can keep all the dates in a single array of k/v pairs and index on this.

It’s perfectly fine to shorten field names and it is sometimes used as a means to reduce the size of larger documents with lots of fields, that said it does come at a cost of understanding so this should always be balanced against space/performance gains.

You might also enjoy this blog post https://www.mongodb.com/blog/post/building-with-patterns-the-attribute-pattern to help add further context on the attribute pattern.

Hope this helps answer your questions.

Kindest regards,
Eoin

[David_Thompson]

I think my question was misunderstood… What I was asking was that in how I see the problem and solution, there is a key: value pair missing. In order to add the field “acquisition_date” to the documents and ensure that it is present in all documents, there needs to be 2 key value pairs… So it would be:

“k”: “value”, “v”: “value”, “u”: “value”

The “u” would be where acquisition_date is and the “value” associated with it would be where the date would go… However, the homework validates with two Key value pair… The way I see it, there should be three Key Value Pairs.

What am I missing in this?

[Eoin_Brazil]

Hi @David_Thompson

My apologies for my misunderstanding. The homework correctly validates based on two key-value pairs. There is no need for three key-value pairs in this particular lesson solution.

The third key pair would be used normally to add further details to ‘decorate’ the data with the specific units as given in the blog post example earlier. This is not required in this instance and would add an unnecessary field/value pair.

Why is a third key-value unnecessary, you ask? It is unnecessary because of the move to key and to value being separate field pairs. The data in this exercise will then typically be stored where the key can either be a location name or the acquisition. This is essentially the benefit from this non-deterministic naming of the field and of the value pairing.

That said, it might be useful to add the third key-value pair to add the size or type of event or indeed to add key-value pairs to further decorate the data. However, in the case of the lesson here for M320, that’s beyond the scope of the lesson so it is only concerned with the two key-value pairs.

Hopefully, this adds some clarity as to why it is only two key-value pairs and that for other scenarios/uses beyond this lesson that a third key value (or more) pair(s) could be used.

Kindest regards,
Eoin

[Andrey_Stepanov]

Strangely the validator accepts two solutions as valid - the one mentioned above by Mr David Thompson and another one. The solution of Mr David Thompson in my opinion is not correct. His schema suggests that for each and every entry in the events array we need to provide two objects - one for the lending event itself, another for the acquisition event. I believe that this solution is redundant and illogical. Illogical as acquisition date has nothing to do with the lending of the item to other museums, and the schema looks like as if we were trying to interbreed a donkey with a dog. Still validator accepts it…

[Khammassi_HoussemEdd (Khammassi Houssem Eddine)]

i had the exact same question as @David_Thompson
but now i understand the logic and the benefit from the non-deterministic naming
Thanks @Eoin_Brazil for such great explanation
thank u both for this enjoyable discussion