Resetting schema script history

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
6/22/2010 11:09:46 AM
Gravatar
Total Posts 1196
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Resetting schema script history

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

1/9/2013 6:13:05 PM
Gravatar
Total Posts 1196
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Re: Resetting schema script history

Hey Joe, I came here to bump this really old request since I ran into the issue again (as I do often when developing new features). But first I took a look at the database and setup code to see what would be involved in doing this. It seems the problem is that there is no link in the database between the schema tables and the feature tables. mp_schemaversion and mp_schemascripthistory are keyed by the folder name housing the feature (ApplicationName/ApplicationID fields), while mp_moduledefinitions and mp_sitemoduledefinitions are keyed on the guid in the feature's configuration file (Guid/Featureguid fields).

For developer convenience and data consistency, I think it would be good to add ApplicationID to the mp_moduledefinitions table and populate it during setup.

If you think this is worthwhile, let me know, and I'll work up and send you code changes to populate the ApplicationID field on mp_moduledefinitions at setup, and cascade delete the schema information during module deletion.

Thanks,
Jamie

1/9/2013 7:02:51 PM
Gravatar
Total Posts 18439

Re: Resetting schema script history

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

1/9/2013 7:06:25 PM
Gravatar
Total Posts 18439

Re: Resetting schema script history

Note also for example that some cms features have no corresponding application id because they have no database tables of their own, ie the twitter, google maps, etc only use module definitions and module settings becaue they have no scripts.

Best,

Joe

1/9/2013 7:10:46 PM
Gravatar
Total Posts 1196
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Re: Resetting schema script history

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

1/9/2013 7:24:57 PM
Gravatar
Total Posts 18439

Re: Resetting schema script history

Its funny, a long time ago I thought calling a cms plugin feature a "module" was not a friendly name, end users don't know what that is, so I started calling them "features", but features and applications are pretty much synonymous, so for developers (including myself sometimes) perhaps I've made things a little worse. The road to heck is paved with good intentions... :-D

1/9/2013 8:42:36 PM
Gravatar
Total Posts 18439

Re: Resetting schema script history

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

1/10/2013 10:00:37 AM
Gravatar
Total Posts 1196
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Re: Resetting schema script history

Hi Joe, I think that's a great idea, and could definitely be used for better cleanup. If we create and populate an mp_applicationfeatures table at setup, with ApplicationID and FeatureGuid columns, we could look at that during feature deletion. If there are no other rows on mp_applicationfeatures with the same ApplicationID as the feature being deleted, it would be safe to also delete the schema entries for that application.

I'll send you some code changes to evaluate. Would you prefer to use mp_applicationfeatures for the table name,  mp_applicationmodules for historical consistency, or something altogether different?

Thanks!

Jamie

 

1/11/2013 10:20:17 AM
Gravatar
Total Posts 18439

Re: Resetting schema script history

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

You must sign in to post in the forums. This thread is closed to new posts.