[Request] Don't enforce suffix on model name about typegoose

[hasezoey]

thanks for asking, would 7114498 solve your request?

[ChrisLahaye]

I can work with that but I think those are still weird default semantics. Why not make suffixing opt-in? If you don't want to do that, maybe don't require a customName but fallback to the base name / class name when disabling automatic names.

[hasezoey]

i think about adding "global" settings, but not in 6.0.0

[hasezoey]

closed, because added in 7114498

[ChrisLahaye]

i think about adding "global" settings, but not in 6.0.0

Would you be open to accept contributions for my proposal of:

• making suffixing opt-in
• using the class name as default base name
• allowing the base name to be overwritten

Unless you disagree of course.

[hasezoey]

using the class name as default base name

it currently does, when not using collection or customName

making suffixing opt-in

its currently opt-out, but like i said i plan on doing global settings

allowing the base name to be overwritten

already possible with automaticName: false and a customName

---

PS: it is currently an opt-out because of not clashing with https://typegoose.github.io/typegoose/guides/advanced/models-with-same-name/

[ChrisLahaye]

I intended to say, make class name the default model name. This should be the default behavior like it has been in all prior versions.

I understand that you want to 'solve' the issue of name clashing but you don't do this by enforcing new weird default semantics. The current behavior (without suffixing) was fine for 99% of the cases, in the remaining 1% when name clashing happens someone wants to have mechanisms available to solve this, but in my opinion this shouldn't change the default behavior to something that is irreversible and drastically different than before.

Now in order to acquire the old behavior everyone needs to annotate with:

@modelOptions({ options: { automaticName: false, customName: 'ClassA' } })
class A

Another implication is that people have been dealing with recursive references as follows:

@prop({ ref: { name: 'ClassB' }, required: true })
public something!: Ref<ClassB>;

Now the name changes to ClassB_collectionName.

I appreciate the work you put in maintaining this fork and I would like to upgrade to your fork as you have welcome additions, but once more I would like to ask you to reconsider.

[hasezoey]

so to collect thing & be on the same level, you want to "reverse" automaticName, to be opt-in instead of opt-out and that customName so-or-so will override the default name?

[hasezoey]

does 6bc907d now fully answer your question?

[ChrisLahaye]

does 6bc907d now fully answer your question?

For me this would work as the model name now matches the class name by default.

Now, lets consider other users. First, some remarks on the proposed commit:

• customName is used as base/model name, unless automaticName is true, then it is used as suffix. This logic is abracadabra which we don't want.
• suffix can be undefined, resulting in a name BaseName_undefined

so to collect thing & be on the same level, you want to "reverse" automaticName, to be opt-in instead of opt-out and that customName so-or-so will override the default name?

Indeed, so what makes more sense is the following:

• automaticNames is opt-in, when enabled model (base) names are suffixed with the collection name
• customName overrides the model (base) name

export function getName<T, U extends AnyParamConstructor<T>>(cl: U) {
  const options: IModelOptions = Reflect.getMetadata(DecoratorKeys.ModelOptions, cl) || {};
  const baseName = options.options && options.options.customName
    ? options.options.customName
    : cl.name;

  if (options.options && options.options.automaticName) {
    const suffix = options.schemaOptions && options.schemaOptions.collection;

    if (suffix) {
      return `${baseName}_${suffix}`;
    }
  }

  return baseName;
}

Although, I would expect most people to use a customName instead of automaticName as it fulfils the same goal while giving control over the model name, unless automaticName is a global option.

Maybe keep it simple while still giving users the tools to work around name clashes:

export function getName<T, U extends AnyParamConstructor<T>>(cl: U) {
  const options: IModelOptions = Reflect.getMetadata(DecoratorKeys.ModelOptions, cl) || {};
  
  return options.options && options.options.customName
    ? options.options.customName
    : cl.name;
}

[hasezoey]

suffix can be undefined, resulting in a name BaseName_undefined

yes it can be undefined, but then it just returns the normal class name, as it worked before automaticName

Maybe keep it simple while still giving users the tools to work around name clashes:

i want to keep automaticName for users that use the same class name (i still dont understand why), but a different collection

This logic is abracadabra which we don't want.

i wanted to preserve the functionality from before automaticName, which i think could be useful