Forum OpenACS Development: Accidently updated news-aggregator => Big Pain...
It therefore decides to drop the package_id, assuming that package_id is magically set in acs-objects in 5.2, which is partially true, but not on upgrade. I commented this out, so noone comes into the pain of looking into the backup file and manually setting the package_id of the acs-object, as this is needed by the news-aggregator-portlet.
Sadly now I'm stuck as I can't add any new sources as it demands an aggregator_id. MichaelS, could you enlighten me what is needed to create a source or even better, fix news-aggregator-portlet so it allows you to create new sources?
In any event, sources should not be tied to packages as they may be used across instances and that bit of RI makes life really tough when you try to drop sources that are no longer in use (to avoid chewing up CPU cycles and database rows on pointless updates) or drop packages. One could argue they shouldn't even be objects (no need for permissions, either) but after talking about this with Dave on IRC, I decided to leave them as objects for now in case we ever wanted to add categorization to the feeds.
Back to the point - unfortunately, I don't have a .LRN install to test on so I can't work directly on the portlet. After taking a peek at the aggregator portlet code, I think it might simply be a problem with the URL being used to access the subscriptions page. Are you using the repository or 5.2 branch? I'll try to check in a change that'll fix it and you can let me know if it works.
Moving forward, if there are any users or developers who would like to work with me to ensure that the portlet continues to function, that would be great.
I do agree with your point that if we store the package_id in the acs-object we should not store that package_id with the na_sources table. But dropping the package_id for easier coding is not the way to go. Please provide an upgrade statement that puts the package_id into the acs-objects before dropping the table.
The idea that a source belongs to only one instance of news aggregator is wrong. A source could be associated with any instance of news aggregator, so if for instance, I remove on instance of news aggreagtor, the source could still be used by other instances, and the row should not be removed when the package instance is removed.
I haven't worked with the portlet architecture but I think the right thing to do would be to add an aggregator_id attribute to the portlet and let the portlet query the DB the same way the full package does, i.e., pull all items belonging to the aggregator_id and sort by date, then source. I'm willing to help sort this out but as I said above, I don't have a portal or .LRN installation to work on.
Nima - yeah, it's still going to be an issue. You can avoid the problem by avoiding the upgrade or by running the 0.9.7-0.9.8 upgrade script by hand and omitting "alter table na_sources drop package_id".
Michael, can you answer me the question why it is mandatory that the package_id is dropped from na_sources? It obviously will break *any* .LRN upgrade that is using news-aggregator. Whereas if we just keep the package_id, news-aggregator would still run.
The .LRN integration has a bug if it relies on na_sources.package_id. The column is totally meaningless. The .LRN code for news aggregator needs to be fixed to associate an aggregator to a class instead of a source.