Unable to find the class count for PanGeneSet

[svengato]

A few of the development mines (CajanusMine, LensMine, LupinusMine, PhapanMine) seem to successfully deploy but were displaying a blank page and (in the console) 500/Internal Server Error. After restarting Tomcat on lupini-mines, these mines start to display the home page, but with the error message

Unable to find the class count.<i>cannot find class count for: org.intermine.model.bio.PanGeneSet</i>

This is similar to issue #34. Maybe these mines were built in 5.1.0.2 or 5.1.0.4 ? If so, do they need to be rebuilt from scratch?

Also ran ./gradlew postprocess -Pprocess=summarise-objectstore, which gives this message:

POSTPROCESS summarise-objectstore FAILED.
org.intermine.objectstore.ObjectStoreException: Problem counting SQL statement "SELECT a1_.id AS a1_id FROM PanGeneSet AS a1_"

[adf-ncgr]

Seems likely that they were built under 5.1.0.2 and never updated when 5.1.0.3 hit the scene due to lack of fanbases. They are each quite small so shouldn't be too hard to rebuild, but maybe straight to 5.1.0.4 would be the most sensible plan? Alternatively, we could try reverting the webapp to 5.1.0.2 and see if that takes care of the immediate need, but moving forward would be my preference. Let me know if you want me to be more involved than at a spiritual level.

[adf-ncgr]

Oh, and since these are just misbehaved development mines, I definitely think we ought to not look back.

[svengato]

("And by spiritual, he doesn't mean pouring grain alcohol on the keyboard!")

I guess my tasks would be:

• [x] Update 5.1.0.4 to use JBrowse 2 and other recent changes (either by merging 5.1.0.3 into it, or committing the same changes separately, whatever makes sense)
• [ ] Start updating development mines to 5.1.0.4, starting with these mines

[svengato]

5.1.0.3 and 5.1.0.4 are mutually mergeable, but we should review Sam's 5.1.0.3 changes to see if there are any conceptual conflicts.

[svengato]

5.1.0.3 and 5.1.0.4 are mutually mergeable,

That refers to the mine-webapp submodule.

mine-java: 5.1.0.3 and 5.1.0.4 can be merged.

mine-dbmodel-resources and mine-webapp-resources: 5.1.0.3 and 5.1.0.4 are identical.

mine-libs: not simply mergeable, but I will examine the .jar files and see what changed - maybe we can choose the latest one.

[adf-ncgr]

I think I've become confused/uncomfortable with the merges you are contemplating. I don't think we want to do anything more than add the changes to support JBrowse2 to both 5.1.0.3 and 5.1.0.4 branches, right?

[svengato]

Such a merge would include some other changes that Sam made, we can discuss them tomorrow.

For now, I am going through each mine and committing the update to the 5.1.0.3 branch of the mine-webapp submodule, so that the 5.1.0.3 branch of each mine is up to date. Nothing involving 5.1.0.4 yet.

[svengato]

Oh, and since these are just misbehaved development mines, I definitely think we ought to not look back.

In other words, do not bother building a 5.1.0.3 version of these mines?

[adf-ncgr]

In other words, do not bother building a 5.1.0.3 version of these mines?

right

[svengato]

Not sure whether "Forget you ever heard the name" or "Don't touch it, don't even look at it" is more pertinent.

[svengato]

Thinking about merge v. separate commits: I guess 5.1.0.3 and 5.1.0.4 are like spacecraft heading to different planets, they are never supposed to merge in the first place, so separate commits could be fine. The JBrowse 2 commit involved only one new file. My other commits to 5.1.0.3 were to add the Vicia and Trifolium icons.

[svengato]

I found a couple of examples where Sam made the same change independently in 5.1.0.3 and 5.1.0.4, but others where he only made the change to one branch, possibly intending to do the same for the other branch in the future. For example, in mine-webapp 5.1.0.3 geneBarchartDisplayer.jsp gets legend-related fields like legendPosition from your mine's webapp/src/main/web.properties, while in 5.1.0.4 legendPosition is still hard-coded.

This leads to (probably accidental) discrepancies, for example ArachisMine implemented the above change in both 5.1.0.3 and 5.1.0.4, while MiniMine implemented it in 5.1.0.4 but not 5.1.0.3 which seems backward. I am trying to figure out what was accidental and what we really should update.

[adf-ncgr]

I agree that the current situation is confusing. Based on my very limited understanding, it seems like we might be in the sort of situation addressed by the so-called git-flow branching strategy described here: https://nvie.com/posts/a-successful-git-branching-model/ (specifically with the need to "support multiple versions of the software running in the wild", though I suppose we could consider whether a one-version-to-rule-them-all build strategy would be feasible). Anyway, if focusing on actually getting everything to a 5.1.0.4 level would simplify figuring out the best path forward, I'm happy to turn in that direction.

[svengato]

Do we eventually want to move to 5.1.0.4 and abandon (archive) 5.1.0.3? Have we already done so for the main branch and 5.1.0.2?

Is there a summary somewhere of differences between the various 5.1.0.x branches? I will check the InterMine site.

[adf-ncgr]

Yes, eventually we'll want all the mines on the same latest and hopefully greatest version (currently 5.1.0.4 but presumably at some point we'll make new data model changes that will warrant a new version).

recall that 5.1.0 is an intermine release while 5.1.0.x correspond to LIS-intermine releases. I don't recall offhand where Sam described the changes between the LIS-intermine tags, but this suggests looking at release issues may be helpful in that regard: https://github.com/legumeinfo/mine-issues/issues/94

[adf-ncgr]

https://github.com/legumeinfo/mine-issues/issues/128 for 5.1.0.4

[adf-ncgr]

https://github.com/legumeinfo/mine-issues/issues/109 for 5.1.0.3

[svengato]

Eurgh. I guess those will keep me busy for a while.