Chapter 4: Patterns (Part 2) Lab: Apply the Polymorphic Pattern validate error

The output:


C:\test\mongodb\m320>validate_m320 pattern_polymorphic --file pattern_polymorphic.json --verbose
Answer Filename: C:/test/mongodb/m320/pattern_polymorphic.json
The document passes validation

Errors:
At least one of your solutions is not passing validation.


Note the contradicting messages (“passes”, then “not passing”). If I deliberately mess up my solution I just get the “not passing” message.

2 Likes

I’m struggling with this one too. Did you know you can change the --verbose parameter to --verbose=2 to get more information about what the validator doesn’t like about your file?

I think the first message is saying that the outermost document is of the right shape, but then the validator goes on to inspect array elements and child documents within the outermost document, and one of more of those children is of the wrong shape.

1 Like

Guys, I just got to this question.

Basically, all that needs doing is adding and replacing fields within each document. But don’t try to reference a replacement field like this:
"recruiting_source": "$program_affiliation"

That was my initial thought but this failed. Just add and replace the relevant fields and specify the correct BSON Type.

2 Likes

@007_jb have you completed this lab then? Do these requirements cover everything we need to do?

  • Across all documents, we will use two fields for name: first_name and last_name.
  • Across all documents, we will use a field called recruiting_source as the indicative field for the document shape.
  • In documents that already have an existing program_affiliation field, we will use the value of this field as the recruiting_source.
  • In documents that don’t have program_affiliation, we will add a new field called recruiting_source.
  • All documents should indicate whether an offer was extended via the extend_offer field.

And do all documents need a recruiting_source field or only those that don’t have a program_affiliation field? And for documents which do have a program_affiliation field, is the recruiting_source field in addition to this, or does it replace it?

1 Like

Indeed I have. I’ve just got one more exam question to go to complete the course.

The questions are sufficient. For recruiting_source, yes as per point 3 and 4. This ensures that all three docs are consistent as per the requirement.

Basically, you need to add fields, replace fields and in the process of replacing some fields you will need to tweak the structure ever so slightly to meet the requirement.

1 Like

OK, I’ve just completed this lab too, and I have to report that I think there’s a bug in the validation script which causes it to report a load of false positives when validating an array.

What I did first was to run the validation script with the --verbose=2 parameter against the original schema before I’d made any changes to it. I fully expected this to fail, but to also give me some useful information about what was wrong with the schema.

What it actually gave me was lots of output with 9 “The document fails validation” section headings. 9 sections when the file I’m validating contains an array of 3 documents? Which section relates to which document?

Daniel confirmed that I had the correct top-level structure of an array containing 3 documents, so clearly there were errors within those documents, but when I tried correcting the errors reported by the validation script, I was finding that the errors I was correcting were going away, but additional errors were appearing in the output, implying that that the correction I’d just made was itself an error, and that to correct it I’d need to undo my original correction.

A new approach occurred to me today to help me understand which section of the validation script’s output related to which of the documents in the file I’m validating. I added an extra field to the first document, which I was pretty sure that the validation script would report as an error:

[
  {
    "foo": "<string>",

Actually the data type could be any valid BSON type, the important thing is that the validation script isn’t expecting a field called “foo”, so I should be able to see which sections of its output relate to the document that I added this rogue field to. And I can. There are 3 of them:

The document fails validation. See errors :

  • (root): recruiting_source is required
  • (root): extend_offer is required
  • (root): Additional property foo is not allowed

The document fails validation. See errors :

  • (root): recruiting_source is required
  • (root): extend_offer is required
  • (root): team_placement is required
  • (root): start_date is required
  • (root): end_date is required
  • (root): technical_skills is required
  • (root): non-technical_skills is required
  • (root): notes is required
  • (root): Additional property candidate_notes is not allowed
  • (root): Additional property engineer_level is not allowed
  • (root): Additional property non-technical is not allowed
  • (root): Additional property years_experience is not allowed
  • (root): Additional property foo is not allowed
  • (root): Additional property previous_employer is not allowed
  • (root): Additional property technical is not allowed
  • education: Invalid type. Expected: string, given: array

The document fails validation. See errors :

  • (root): recruiting_source is required
  • (root): extend_offer is required
  • (root): team_placement is required
  • (root): start_date is required
  • (root): end_date is required
  • (root): skills is required
  • (root): notes is required
  • (root): Additional property non-technical is not allowed
  • (root): Additional property technical is not allowed
  • (root): Additional property years_experience is not allowed
  • (root): Additional property candidate_notes is not allowed
  • (root): Additional property engineer_level is not allowed
  • (root): Additional property foo is not allowed
  • (root): Additional property previous_employer is not allowed

So I’ve got 3 contradictory reports about what’s wrong with the first document. I’ll take a chance that the first one is the accurate one, that I just need to add recruiting_source and extend_offer fields to this document. Once I’d done that and run the validation script again, I found one of the sections in the output contained only one error:

The document fails validation. See errors :

  • (root): Additional property foo is not allowed

So that particular test is now only reporting the error that I deliberately introduced, so I’ve probably implemented everything else that I need to do in that document. So I removed the rogue “foo” property from that document and ran the validation script again, and this time my output included this:

The document passes validation

There is light at the end of the tunnel :slight_smile:

But there are a bunch of other errors in the output, because I haven’t updated the other two documents to meet the requirements of the lab yet. So I added that rogue “foo” field to the second document, studied the sections of the output which complained about it (3 of them again, and again, contradictory), picked the most likely one and implemented the changes that it said was needed, ran the validation script again and removed the “foo” field once I was happy that I’d updated the document correctly. And then I repeated the whole process a 3rd time for the 3rd document.

And once I’d finished updating the file and validated it for the final time in order to get a validation code (which was marked as correct), the validation script was still giving me lots of output about my documents failing validation.

This is what I think is happening. When presented with a single document to validate, the validation script works fine. But when presented with an array of documents to validate against an array of expected shapes of those documents, I think the validation script is validating every document in the array against every expected shape in the other array, rather than just validating each document against the expected shape for that document, and even though it returns a working validation code once the documents are correct, it’s still outputing lots of false positive error messages (when run with --verbose=2).

No wonder I was getting confused…

I appreciate that this is a new course and there are some rough edges to be smoothed out, and I hope @danielcoupal and the other MongoDB University folks will accept this feedback in the constructive spirit with which it is intended :slight_smile:

4 Likes

You guys are early takers of this course, so we absolutely value your feedback even more!

I see the issue Simon is talking about.
Validating 1 answer against 1 solution is easy, and the validator can tell exactly the mismatches.
Validating 3 answers against 3 solutions is done by doing the 9 permutations, each answer against each solution and keeping track of the successful matches.
If one answer is wrong, it will generate 3 sets of comments. One should be small, the one that is close to the solution, but the 2 other will be too verbose.

To reduce the noise, we would need to either report errors for the closest solution among the 3.
If only one answer is wrong, it is also easy to conclude the mismatch comparison and report only those mismatches. If more than one answer is wrong makes it more complicated.

Alternatively, we order the solutions and ask to provide the answers in the corresponding order, then the validator only compared answer1 with solution1, answer2 with solution2 and answer3 with solution3.

Again, thanks for the feedback,
Daniel

Thank you to Simon_39939 for --verbose=2 and for his analysis.

Running:

validate_m320 pattern_polymorphic --file pattern_polymorphic.json --verbose=2

The output is divided into 9 sections, each starting with the string “The document”.

The first document’s true output is section 1

The second document’s true output is section 5

The third document’s true output is section 9.

Ignore all the other sections from the --verbose=2 output.

4 Likes

Hi,
i have a “stupid question” for all people!
Why in the third document shape of the outermost document we have the education array defined as below?
Is it a mistake?

“education”: [{
“level”: “”,
“subject”: “”
},
{
“level”: “”,
“subject”: “”
}

],

@Gianfranco_15573, it’s an array of a dictionary, or an array of key:value pairs. With this schema, it allows you to enter two qualifications under education:
image

Ok but in this case in the schema I should have found an array like this
"education”: [{
“level”: “”,
“subject”: “”
}]
Note that into the array of the schema we have two documents equals divided by a comma, not one with four fields.
Is there anything that i don’t understand?

@Gianfranco_15573 I wouldn’t worry about that.


Only the fields in bold are relevant, anything else is irrelevant for this lab.

2 Likes

@danielcoupal I’ve been thinking some more about how the validator could be improved to make this lab less confusing. I think the most important thing is to remove the cross join between the 3 documents being validated and the 3 expected shapes (apologies for the relational database terminology) and thereby remove all the noise caused by validating a document against the expected shape for a different document. Three ways of doing this come to mind…

  1. Require the student to supply the schema documents in a particular order in the array, and validate document 1 in the array against expected shape 1, document 2 against expected shape 2 and so on.

  2. Require the student to save each of the 3 documents as a separate file and call the validation script for each one, e.g.

    validate_m320 pattern_polymorphic1 --file pattern_polymorphic1.json
    validate_m320 pattern_polymorphic2 --file pattern_polymorphic2.json
    validate_m320 pattern_polymorphic3 --file pattern_polymorphic3.json

  3. Require the student to save each of the 3 documents as a separate file and supply all 3 filenames to the validation script, e.g.

validate_m320 pattern_polymorphic --file1 pattern_polymorphic1.json --file2 pattern_polymorphic2.json --file3 pattern_polymorphic3.json

Option 1 feels a bit wrong to me, because the order in which objects and fields appear in a JSON document shouldn’t normally be significant.

Options 2 and 3 feel cleaner, although option 2 would probably result in 3 validation codes for a single lab, which may cause a headache for the developers who maintain the server side magic which keeps track of our progress through the course and whether we’ve attempted / passed / failed each lab. Similarly, option 3 may cause a headache for the developers who maintain the validate_m320 code. Without having sight of the codebase for either, I don’t know which would be a bigger headache (and I’m generally in favour of not giving developers headaches).

Just a suggestion…

Валидатор путает множественными и на первый взгляд противоречивыми сообщениями, но при желании можно разобраться.
Он каждую схему проверяет на валидность по всем шаблонам, поэтому один раз скажет что"…passes" и два раза - “fails”.
Солюшен: каждую схему копать по отдельности, поставив вместо двух других пустые фигурные скобки. А после этого скопировать все схемы в один файл, проверить и получить заветный код.

1 Like

Thank you @007_jb , this helped to pass the test.

Thanks @atuljssate… team effort

2 Likes

Hi all,

I already replaced --verbose=2 by --verbose=5, after that I did as the guide.
And it worked

Thank you @David_18019 this helped me to pass

I got the correct code but on submitting, I got a message to the effect - . ‘Error diplaying the problem’

Lost three attempts on this .

Thank you for the detailed explanation. This helps me passed.