Yogi, sorry for the late reply, yesterday I was not able to answer your post, too.
For example, the new links feature will be completely broken. Have a look at the code in Build.pm and you will see why.Yes, you are right, we will have problem in new links feature. It is my responsibility to manage these and other problems, what may occured by a db upgrade.
(the database upgrade we are talking is not very serious, just a field type change, what can be solved without data loss, and can be restored without data loss!)
Further into from one of my earlier posts: "Very likely will not affect (at least in not too many places) the core code, since we have the 'date_db_format' config variable, so we can define how the dates was stored in the database."
Hopefully all these problems can be managed down.
Of course and upgrade only worths, if all problems what it caused can be managed, and corrected.
Yes, I'm aware of this, and I change the type of Newest_Link field, too.
I don't think so. My opinion is, that if a database structure is not good for a specific task, then it should be changed, upgraded. And current database is not suitable for me, and supposedly for a few other users, too.
And Yes, it is the responsibility of the developer (me), to make that db upgrade optional, and restorable if possible. If db upgrade modifications can not be restored, then warn the user before they buy and use such product.
I aggree. A plugin should not break core Links features, only improving them! If it would break the core Links features, it would mean it is simply not worth to release it...
I can promise, I will only release it, if it will not break core Links features, right?
In case if Alex would aggree to upgrade to date-time usage, then would need a bit modification (adding a few lines) for the new links feature and maybe at a few other places, too.
But as I stated earlier, I do not ask Alex to do that, just suggested to make LSQL more universal in some respects.
In case, if I do database upgrade, I have to be very careful, to take care of the needed changes, what a such database upgrade would need to keep all LSQL features working well.
If I would do such database upgrade in plugin installation, then I do it OPTIONAL, and I do it reversible. When the user uninstalls the plugin, it would restore the previous type, and change data back to yyyy-mm-dd format. If you think about in details, you will find that upgrade & degrade is not really difficult, and can be done without user data loss.
So if I would do any upgrades, I would make it optional, uninstallable, and non-destructive.
I hope this clarification, will calm down upgrade related worries.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote:
but it would conflict with the Links SQL core code (that's what Alex also said, if you carefully read his post above). For example, the new links feature will be completely broken. Have a look at the code in Build.pm and you will see why.
(the database upgrade we are talking is not very serious, just a field type change, what can be solved without data loss, and can be restored without data loss!)
Further into from one of my earlier posts: "Very likely will not affect (at least in not too many places) the core code, since we have the 'date_db_format' config variable, so we can define how the dates was stored in the database."
Hopefully all these problems can be managed down.
Of course and upgrade only worths, if all problems what it caused can be managed, and corrected.
Quote:
Plus, you would also have to change the Newest_Link field in the Category table to DATETIMEQuote:
I think that the definitions of the system columns should be left as they are.And Yes, it is the responsibility of the developer (me), to make that db upgrade optional, and restorable if possible. If db upgrade modifications can not be restored, then warn the user before they buy and use such product.
Quote:
I personally would not want to buy a plugin that changes my existing columns, especially if it breaks core Links featuresI can promise, I will only release it, if it will not break core Links features, right?
In case if Alex would aggree to upgrade to date-time usage, then would need a bit modification (adding a few lines) for the new links feature and maybe at a few other places, too.
But as I stated earlier, I do not ask Alex to do that, just suggested to make LSQL more universal in some respects.
In case, if I do database upgrade, I have to be very careful, to take care of the needed changes, what a such database upgrade would need to keep all LSQL features working well.
If I would do such database upgrade in plugin installation, then I do it OPTIONAL, and I do it reversible. When the user uninstalls the plugin, it would restore the previous type, and change data back to yyyy-mm-dd format. If you think about in details, you will find that upgrade & degrade is not really difficult, and can be done without user data loss.
So if I would do any upgrades, I would make it optional, uninstallable, and non-destructive.
I hope this clarification, will calm down upgrade related worries.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...