Extending Models

[Kaffiend]

Is it possible or is there an example to extending models? Such as say a config collection houses a header type (base) config, and multiple other config models all with the same index in the same collection? My first guess is just build multiple models with the same collection, db, and indexes as their own "schema" is that the intended method or is there some typescript leveraging I'm overlooking to extend a base iridium model with another iridium model? I'm most likely overthinking this and its much simpler than I'm currently thinking.

[Kaffiend]

basically something along these lines..

@Collection('configs')
@Index({ configName: 1 })
export class BaseConfigSchema extends Instance<ICountyConfig, BaseConfigSchema> {
    @ObjectID
    public _id: String;
    @Property(String)
    public configName: string;
    @Property(String)
    countyName: String;
}
export class AssessorConfigSchema extends BaseConfigSchema {
    @Property(String)
    assessorName: String;
}
class BaseConfigDatabase extends Core {
    public config = new Model<ICountyConfig, BaseConfigSchema>(this, BaseConfigSchema);
}
class AssessorConfigDatabase extends Core {
    public config = new Model<ICountyConfig, AssessorConfigSchema>(this, AssessorConfigSchema);
}

export const baseConfigDb = new BaseConfigDatabase({ database: 'test_db' });
export const assessorConfigDb = new AssessorConfigDatabase({database: 'test_db'});

this seems to work fine, but im porting over a legacy app and these obviously a lot more to these config files and i dont want a monolithic schema declaration and want to break these up and at some point as i progress through the migration i want to redefine these to clean things up. Is there any issue building multiple stand alone models against the same collection with indexes and such with Iridium? I know mongo doesnt care i was just curious as to some insight before i drudge down this path, there is a lot of configuration to this legacy app that needs refactored but im starting with a one to one conversion. 😄 COBOL => Mongo

[notheotherben]

It should be perfectly fine to do so if you're using the decorators, the way they're implemented means that they should be safe to layer. That being said, I don't currently have a unit test case which demonstrates this usage, so let me quickly add one to make sure it doesn't get broken by any future updates.

My only caution would be that there is no validation preventing you from using an invalid combination of schema properties by combining the various models, but I don't imagine that'll be a huge issue for you.

[Kaffiend]

In the COBOL there is a lot of duplicate properties across models that were used as alternate keys that will become irrelevant as i refactor. Since they exist in all the models i figured that would work well for a base class and not have to duplcate across each model as i go.

…

On Jul 21, 2017 5:30 PM, "Benjamin Pannell" ***@***.***> wrote: It should be perfectly fine to do so if you're using the decorators, the way they're implemented <https://github.com/SierraSoftworks/Iridium/blob/release/lib/Decorators.ts#L98> means that they should be safe to layer. That being said, I don't currently have a unit test case which demonstrates this usage, so let me quickly add one to make sure it doesn't get broken by any future updates. My only caution would be that there is no validation preventing you from using an invalid combination of schema properties by combining the various models, but I don't imagine that'll be a huge issue for you. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#91 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHdrNeFxK1Ig0O7QmJpq2CWoRu-2XUJeks5sQRhdgaJpZM4Of2gt> .

[Kaffiend]

Thanks @spartan563 i think in the long run it may behoove me to just stay with the individual classes and repeat as needed, in the interest of consistency, and explicitness. As always, I appreciate your Insight and quick response!

Ill leave this open until the unit test is in place and referenced.
Ian