Hi

Hoping someone can suggest something here:

As part of SS2.x -> 3.x upgrade, I'm also doing an upgrade of all 3rd-party modules, and a refactoring of modifications made directly to some of those modules, so that future upgrades are straightforward. This includes the blog module.

• The blog module was modified by having a ROIBlogPage class inserted into the inheritance hierarchy between Page and BlogEntry / BlogTree, and some custom classes (PressReleaseEntry based off BlogEntry, and PressReleaseHolder based on BlogHolder) were located in the blog module dir

• I’ve factored any custom classes back out again (see attached) and am aiming to have the blog module ‘pure’ again, with any customisation in the subclasses under /mysite

• There’s still a bit of work to do, but I’ve encountered a more fundamental problem:
  when building the schema, the build process is creating a PressReleaseEntry.ParentID column which, naturally, breaks several SQL statements since it duplicates the SiteTree column of the same name.

• I cannot work out why it is doing this, and have search the code, googled the forums etc. for anyone with similar problems, but have only encountered folks who have tried to JOIN with another table with a ParentID field (such as File), which is not the case here.
  

Attached is an outline showing the original (customised) class hierarchy, and the refactored hierarchy. I am not 100% certain if the issue is caused by this refactoring, or the fact that the blog module has been upgraded, or something else (the SS3 framework upgrade etc.)

Obviously, I've only made the absolute minimum changes necessary to perform the upgrade and refactor customisations to the blog module out, so I haven't been adding additional properties, relations etc.

Can anyone call out possible reasons why the build process would now be adding the ParentID column to the PressReleaseEntry table?

It sounds like the PressReleaseEntry model may have a has_one or some other type of join to another model.

It might be an idea to show the code from the PressReleaseEntry model in the post.

Hi Kirk

Thanks for querying.

Managed to resolve this:

actually this was the original code having 'Hierarchy' extension defined in the PressReleaseEntry class - which seems wrong, as utimately this class inherits from SiteTree, which does the same. For some reason this did not create the superfluous PressReleaseEntry.ParentID column in the original 2.4 installation, but does in 3.1, and the SQL breaks.

I've just removed this extension declaration from the PressReleaseEntry and all seems fine (so far - more QA to be done).

Thanks
Paul