Skip to content
This repository has been archived by the owner on Jun 29, 2021. It is now read-only.

Solve #376: clashing in case of more classes with the same name #384

Closed
wants to merge 15 commits into from

Conversation

fabioformosa
Copy link

@fabioformosa fabioformosa commented Aug 27, 2019

What does the Feature do

This PR avoids clashing in validation check, if more classes has the same name.

  • With typeAlias attribute in @prop() is possibile to disambiguate name of types used as nested object.
  • With typeAlias attribute in GetModelForClassOption is possible to disambiguate models with the same class name.

Please, look at:

Related Issues

@coveralls
Copy link

coveralls commented Aug 27, 2019

Coverage Status

Coverage increased (+0.5%) to 88.09% when pulling b0aae66 on fabioformosa:master into aaec1bf on szokodiakos:master.

@hasezoey
Copy link
Contributor

hasezoey commented Aug 27, 2019

sorry, but could you re-target it to the r6/master (on my fork)?
-> to be in version 6.0.0

PS: please read the CONTRIBUTING file and how to structure commits for PR's, thanks (i mean especially to squash as needed, thanks)

@fabioformosa
Copy link
Author

fabioformosa commented Aug 27, 2019

sorry, but could you re-target it to the r6/master (on my fork)?
-> to be in version 6.0.0

Yes, I can. But I'm using the current version 5.9.0, and I'm very interested to have this feature in ver 5.
Could you merge, please? Have you permission to merge and to publish in npm registry?

PS: please read the CONTRIBUTING file and how to structure commits for PR's, thanks (i mean especially to squash as needed, thanks)

Where's the CONTRIBUTING file?

@hasezoey
Copy link
Contributor

Where's the CONTRIBUTING file?

to your right, when you start an pull request, otherwise here


Have you permission to merge and to publish in npm registry?

that is the reason why v6 is currently not on the offical npm & offical repo(this one here), because only @szokodiakos can give the rights to this

but v6 is release under @hasezoey/typegoose@next and in #365 is the changelog


here are some things my fork has, but the offical repo (this one) dosnt: hasezoey#1

@fabioformosa
Copy link
Author

@szokodiakos can give the rights to this

I'm confused!
From npmjs.com, I see that @Ben305 has rights to publish.

Hi @Ben305, please could you clarify me some points:

  • Are you currently the maintainer of this project?
  • Could you accept my PR?
  • Could you publish a new version?

@hasezoey
Copy link
Contributor

hasezoey commented Aug 28, 2019

Are you currently the maintainer of this project?

yes he is a maintainer (/collaborator), but currently dosnt do any code changes & Accepting PR's (look at the still open ones, and how "old" they are), only currently accepted changes are documentation changes, hes not often doing much here in the last time

PS: look at #99

PPS: what the transfer would do / should do / can do: typegoose/typegoose#1 (comment)
but never got an reaction from ben after this holidays

@hasezoey
Copy link
Contributor

btw i am now looking through your pr a bit, and it seems you modified many documentation changes (Readme, etc) that are "not related" to the actual solving of "clash in case of more classes with same name", so could you spread it in multiple PR'S?

@fabioformosa
Copy link
Author

btw i am now looking through your pr a bit, and it seems you modified many documentation changes (Readme, etc) that are "not related" to the actual solving of "clash in case of more classes with same name", so could you spread it in multiple PR'S?

Unfortunately some format option caused diff also in rows that I didn't edit.
I will try to understand if is a format option of my IDE or a formatter included in the project (like prettier).

@fabioformosa
Copy link
Author

yes he is a maintainer (/collaborator), but currently dosnt do any code changes & Accepting PR's (look at the still open ones, and how "old" they are), only currently accepted changes are documentation changes, hes not often doing much here in the last time

PS: look at #99

I've just pushed @szokodiakos to grant you maintainer permission as asked by Ben in #99

@hasezoey
Copy link
Contributor

I've just pushed @szokodiakos to grant you maintainer permission as asked by Ben in #99

yes i saw

Copy link
Contributor

@hasezoey hasezoey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add a test with "typeAlias" for

typegoose/src/utils.ts

Lines 81 to 88 in aaec1bf

/**
* Get the Class for a given Document
* @param document The Document
*/
export function getClassForDocument(document: mongoose.Document): any {
const modelName = (document.constructor as mongoose.Model<typeof document>).modelName;
return constructors[modelName];
}

for reference
https://github.com/szokodiakos/typegoose/blob/master/test/tests/getClassForDocument.test.ts

@fabioformosa
Copy link
Author

please add a test with "typeAlias" for
I've already written it. See test/tests/typeAlias.test.ts

@hasezoey
Copy link
Contributor

I've already written it. See test/tests/typeAlias.test.ts

nope, cant find it

@fabioformosa
Copy link
Author

I've already written it. See test/tests/typeAlias.test.ts

nope, cant find it

It's true. I'm going to understand this function and I'll write a test.

@hasezoey
Copy link
Contributor

I'm going to understand this function and I'll write a test.

trying to help: this function gets the class from the the supplied document, if it can be found in the class "array" (not in 6.0.0 its a map)

- Tested getClassForDocument() for a model created using typeAlias
@@ -45,12 +46,18 @@ export function suite() {
expect(userReflectedType).to.not.equals(CarType);
});

it(`should return correct class type for document also using typeAlias`, async () => {
const event = new EventModel();
Copy link
Contributor

@hasezoey hasezoey Aug 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but are you sure that it is just this model, when only having one named "Event"?
-> please add to be sure an dummy Event(Class) and make it have different properties, thanks

PS: shouldnt this test be in typeAlias.test.ts? (im not fully sure)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'm sure. As you asked, I've added another model named Event with different properties and typeAlias.

@hasezoey
Copy link
Contributor

hasezoey commented Sep 4, 2019

does this | f73cca0 somehow relate what this pr tries to achieve?

@fabioformosa
Copy link
Author

fabioformosa commented Sep 4, 2019

hi @hasezoey, It seems to me that f73cca0 solves different models (extending typegoose) with same class name.
But it doesn't solve the case of subtypes (not extending typegoose class) with same class name. Do you agree?
my PR has some troubles, I'm fixing them.

@hasezoey
Copy link
Contributor

hasezoey commented Sep 4, 2019

the listed commit, is from version 6.0.0, so "extending typegoose" is deprecated, and is not used

PS: if you got redirected to a wrong URL, sorry, my bad, fixed it

@fabioformosa
Copy link
Author

fabioformosa commented Sep 4, 2019

Could you apply your commit to this project that reproduces my error with class name conflict?
https://github.com/fabioformosa/typegoose-validation-error
You should replace in package.json typegoose 5.9.0 with your version and run test. Thank you.

@hasezoey
Copy link
Contributor

hasezoey commented Sep 4, 2019

(didnt test or run it yet, but wanted to say some things:)

the commit i listed here, makes differing models, with "same name", but only if you add an option for "collection" or a "customName" into @modelOptions

@fabioformosa
Copy link
Author

fabioformosa commented Sep 4, 2019

Ok so I'm sure that it cannot work in my case, because I have a conflict between two classes with same name but one (bar) is a model (with @modelOption) and the other one (bar) is a subtype (with no collection) of foo.

@hasezoey
Copy link
Contributor

hasezoey commented Sep 4, 2019

i just run your thing, changed it to v6 syntax, and no build errors, should i look at something different?

@fabioformosa
Copy link
Author

Have you launched npm test? do they pass?

@fabioformosa
Copy link
Author

fabioformosa commented Sep 4, 2019

  • one fails: "fieldTwo": Path fieldTwo is required
    otherwise it runs fine

So this proves that your version doesn't fix the case reproduced here https://github.com/fabioformosa/typegoose-validation-error and explained in #376

@hasezoey
Copy link
Contributor

hasezoey commented Sep 4, 2019

as you can see, i deleted my comment, because i did something wrong, will report again

@hasezoey
Copy link
Contributor

hasezoey commented Sep 4, 2019

i ran npm build: passes


npm test: both passes

give me write permission to your test repo, and i will give the change to you (in a different branch, to compare)

@fabioformosa
Copy link
Author

give me write permission to your test repo, and i will give the change to you (in a different branch, to compare)

I've just given it to you

@hasezoey
Copy link
Contributor

hasezoey commented Sep 4, 2019

pushed to typegoosev6

@fabioformosa
Copy link
Author

I got, but npm install raise error. Have you pushed your package in public npm repo?

@hasezoey
Copy link
Contributor

hasezoey commented Sep 4, 2019

no https://www.npmjs.com/package/@hasezoey/typegoose/v/6.0.0-25 | npm i -s @hasezoey/typegoose@next

PS: i use npm i -D to install all dependencies & dev ones

PPS: what is it for an error?

@fabioformosa
Copy link
Author

Ok npm problem solved.

I have a question: Why did you add getModelForClass(Bar) to the nested bar ? This bar hadn't model in master branch.

@hasezoey
Copy link
Contributor

hasezoey commented Sep 5, 2019

Why did you add getModelForClass(Bar) to the nested bar ? This bar hadn't model in master branch

because i prefer

const bar = new BarModel({ fieldOne: 'fieldOne', fieldTwo: 'fieldTwo' } as Bar);

return await FooModel.create({ bar: bar } as Foo);

over

const bar = new Bar();
bar.fieldOne = 'fieldOne';
bar.fieldTwo = 'fieldTwo';

const foo = new Foo();
foo.bar = bar;

const fooModel: InstanceType<Foo> = new FooModel(foo);
return await fooModel.save();

the main difference i mean with it:

const bar = new Bar();
bar.fieldOne = 'fieldOne';
bar.fieldTwo = 'fieldTwo';

@fabioformosa
Copy link
Author

Ok, test passed.
I expected you applied the new option customName to one of two Bar classes or both of them, but not.
How did you avoid conflicts on Bar class name?

@hasezoey
Copy link
Contributor

hasezoey commented Sep 5, 2019

does this solve your question?

TL;DR: if schemaOptions: collection is supplied, it adds _collectionname to the modelName

@hasezoey
Copy link
Contributor

this can be closed because it will not be included in this repo anymore
(and i tried to integrate it | self-made version in v6.0.0, and failed)

@Ben305

@Ben305 Ben305 closed this Sep 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants