Hi Joe, I am developing a custom feature, and had a problem where my schema install script wouldn't run at setup. I tried deleting the feature and reran the setup, but still no go on the script. Eventually, I discovered I had to delete the feature's rows on mp_schemascripthistory and mp_schemaversion, then rerun setup.

Wouldn't it make sense to cascade delete rows on those schema tables when deleting features from the system? If you think those rows should remain in the database, you may want to work these manual schema cleanup steps into the developer documentation for future reference.

Thanks as always,

Jamie

Hi Jamie,

I totally get why it seems like featureGuid should correspond to application guid, I remember a while back I had forgotten how it worked and I looked into that myself thinking I would make that correlation but then realized they are not the same thing and why it wasn't done that way.

ApplicationID corresponds to database installation and the guid for that is created at the time when the application folder is discovered by the setup sytem and logged into the mp_SchemaVersion table after running the first script, then updated if any additional scripts are run. By the conventions it knows where to run the db scripts in sub folders beneath the application folder. Within those folders a given application may have any number of cms "features" each with their own feature guid and SiteModuleControl. ie there can be any number of feature definition files beneath the application folder and a given file can also contain multiple features. Module settings correspond to specific features within the application. The reading and configuring of module definition settings only happens after the database scripts have run.

Consider that there are several "features" within mojoportal-core. There are also many features in the mojoPortal.Features.UI project and most of those features do have a one to one correspondence to an application under mojoPortal.Features.UI/Setup/applications it is not a rule and is not guaranteed. The application folder for kdmediaplayer for example has 2 "features" one for audio and one for video but they use the same schema and upgrade scripts. There could also be applications that have no cms plugin "features", ie bolt on applications as we have discussed before that need to leverage the setup system for database schema without any requirement for cms features. 

Best,

Joe

Okay, now I get it. So this is more of a design limitation since the schema can include scripts for many features living under the same application folder name. Thanks for the clear explanation of that. I get so involved in individual feature creation, and always create a new "application" for each feature I make, to keep the schema files separated, so I've been missing the bigger picture.

Jamie

Hi Jamie,

One idea just occurred to me. If you want to submit code changes that correlate application guid with feature guid in the database that would be something I would consider if it would help your scenario.

ie, even though the step that processes feature definition files is after the db "application" schema updates for a cms feature, there could be something that runs after that, to update/sync a new table in the db with feature guid and application guid based on the parent folder name. 

If having such data would help in the same way for you, I'm open to it.

Best,

Joe

Hi Jamie,

Really ApplicationID could/should have been named SchemaID or SchemaGuid since it represents a schema. I'd name the new table mp_SchemaFeatures but use ApplicationID and FeatureGuid to be consistent with existing columns.

Populating this table should not require any changes for developers. I'm envisioning another routine that runs at the end of setup and loops through the application folders, looks up the ApplicationID (there is an existing method for this, I think it returns guid.empty if not found), and only if it exists then loop through the feature definitions and insert only if the featureGuid does not exist in the new table. 

So features that have no schema/application id will not be listed in the table. Technically there still could be features that have no schema of their own nested below an application folder that may have a schema to support other features. ie the app folder has some features that have sql scripts and some that don't. So it is still a very loose relationship since there is no guarantee that a given feature guid nested below the app folder is really related to the schema. Only if all the app features below an app folder were deleted would it really be safe to remove the schema unless you know by other means which ones really use the schema.

To be honest I don't see any huge advantage to adding this extra table that will rarely be used, seems like make work to me. The method signatures would have to exist for all supported db platforms so the methods should probably be voids with no return types like

public void AddSchemaFeatureIfNotExists(Guid applicationGuid, Guid featureGuid) 

that way they don't really have to be implemented for all data layers, the method could do nothing in some data layers.

Best,

Joe