search

agiletiger / ojotas

The database-first ORM
MIT License
7 stars 4 forks source link

implement hasOne relation #6

Closed nicoabie closed 10 months ago

nicoabie commented 10 months ago

same as hasMany in assemble but for 1:1 relationships

qmohitsingh commented 10 months ago

hey @nicoabie , could you please assign this to me? Also, do we need to add unit test cases?

nicoabie commented 10 months ago

Assigned good sir! Yes, it is very important that we add unit test to all the PRs we work on.

qmohitsingh commented 10 months ago

Assigned good sir! Yes, it is very important that we add unit test to all the PRs we work on.

Awesome!! Thanks

qmohitsingh commented 10 months ago

hey @nicoabie , can you pls review this one test case and let me know if it is valid?

test('assemble hasOne relation with complex data ', () => { const objects = [ { 'p.personId': 1, 'c.contactId': 101 }, { 'p.personId': 1, 'c.contactId': 102 }, { 'p.personId': 2, 'c.contactId': null }, { 'p.personId': 3, 'c.contactId': 101 }, { 'p.personId': 4, 'c.contactId': 103 }, { 'p.personId': 5 }, ]; const relations: Relations = { person: { contact: ['hasOne', 'contactDetails'], }, }; const aliases = { p: 'person', c: 'contact', }; const identifiers = ['p.personId', 'c.contactId'];

assert.deepStrictEqual(assemble(relations, aliases, identifiers, objects), [ { personId: 1 }, { personId: 2 }, { personId: 3 }, { personId: 4, contactDetails: { contactId: 103 } }, { personId: 5 }, ]); });

The output of this test case reflects the following rules and assumptions:

Ignoring Multiple Contacts for One Person: personId: 1 is associated with two different contactIds (101 and 102). However, since the relationship is hasOne, the function ignores these multiple associations, resulting in { personId: 1 } without contact details.

Handling Null Contact ID: personId: 2 has a null contact ID. This is interpreted as having no associated contact details, resulting in { personId: 2 }.

Avoiding Shared Contact IDs: Both personId: 1 and personId: 3 are associated with contactId: 101. In a strict hasOne relationship, this shared association is not allowed. Therefore, both personId: 1 and personId: 3 are listed without contact details.

Valid Contact Association: personId: 4 has a unique contactId: 103, which is correctly associated, resulting in { personId: 4, contactDetails: { contactId: 103 } }.

Person Without Contact Details: personId: 5 has no associated contact details, so it appears as { personId: 5 }.

nicoabie commented 10 months ago

Thanks for the detailed description.

I think the first one is not a valid test case because the user explicitly said there is a hasOne relationship so the database will not send more than one.

Also the shared contact id is fine, in this scenario it makes no sense because of the entities you chose but from a strong point of view hasOne does not imply that that one is unique

The other test cases are fine and enough

nicoabie commented 10 months ago

implemented in https://github.com/agiletiger/ojotas/pull/28