Questions about the example plugin

[ZagGrad]

I'm hoping someone can help me with a few questions I have regarding the example plugins. While I have a decent amount of experience programming, it's mostly for embedded systems; I'm brand new to c#, visual studio, and programming for Windows. I say that because the questions might be...not the most difficult to answer.

So, the example mentions that if a plugin is to be distributed there should be a separate plugin available for each minor release. How come? Is this mandatory? It seems like the program changes in the minor versions don't affect the entire program, so wouldn't a plugin likely work for minor versions released after the plugin is written? Should updates for minor versions be pushed to users, or should a new version just be made available for people who have updated versions?

Also, the example plugin creates an entry in the preference table for storing the database version. Why is this done? I'm thinking it might have to do with keeping track of which database version was in use when the plugin created the tables it uses. Am I on the right track?

I read the Open Dental update procedure, but I'm still wondering how the database is updated. If I create a table with the plugin, will that table still be accessible if the Open Dental database is updated? I'm assuming it would. But if the update procedure only copies the Open Dental tables, not all the tables in the database, then it seems like the plugin table could get left behind.

Finally, there is a big note, in all caps, to remember never to use a "0" versions (HEAD). Does this actually have anything to do with plugin? I mean, I couldn't accidentally cause a user to use a "0" version could I? I'm thinking maybe this is just a reminder to users not to use a self compiled version of Head with their live data.

Sorry for the super long post. I'm grateful for any advice you can provide.

-Ryan

[jordansparks]

So, the example mentions that if a plugin is to be distributed there should be a separate plugin available for each minor release. How come? Is this mandatory? It seems like the program changes in the minor versions don't affect the entire program, so wouldn't a plugin likely work for minor versions released after the plugin is written? Should updates for minor versions be pushed to users, or should a new version just be made available for people who have updated versions?

I can't find where it mentions that. But in Open Dental, a minor version change, such as from 11.2 to 11.3 is exactly as significant as moving from 11.6 to 12.0 ( as long as 11.6 was the last of the 11.x versions). The major version (11 in the example) is simply the year. It doesn't mean that there was a big change. And I would say that the main reason for releasing matching dlls is for clarity. It would be nice if there was an 11.3 dll available for the 11.3 version of OD. It's confusing if the dll version is 11.2 and OD is at 11.3.

Also, the example plugin creates an entry in the preference table for storing the database version. Why is this done? I'm thinking it might have to do with keeping track of which database version was in use when the plugin created the tables it uses. Am I on the right track?

Yes. It's the only way for a plugin to make changes to the schema without blowing up.

I read the Open Dental update procedure, but I'm still wondering how the database is updated. If I create a table with the plugin, will that table still be accessible if the Open Dental database is updated? I'm assuming it would. But if the update procedure only copies the Open Dental tables, not all the tables in the database, then it seems like the plugin table could get left behind.

The update procedure sends queries to the database to change the schema. When it makes a copy, that's only for backup purposes in case something goes wrong. Anyway, the copy would also contain your special tables.

Finally, there is a big note, in all caps, to remember never to use a "0" versions (HEAD). Does this actually have anything to do with plugin? I mean, I couldn't accidentally cause a user to use a "0" version could I? I'm thinking maybe this is just a reminder to users not to use a self compiled version of Head with their live data.

Right. This is just a reminder to not use a self compiled version of the head with live data. The schema is in flux, and it would end up "partially converted".

[ZagGrad]

Thanks for the clarification!