Debug output shows non-existent Doctrine index type YES_NO being referenced

[rowanthorpe]

When "debug" is on the following URLs show varying between one and ~hundred repeats of the following warning: Notice: Undefined index: YES_NO in /[PATH]/[XX].php on line [X]

/customer/details
/customer/unread-notes
/customer/list
/user/list
/contact/list
/contact-group/list
/switch/list
/switch-port/list
/mac-address/list

From scanning the code it seems YES_NO is not defined where other similarly used index types are, but I don't know Doctrine well enough to fix it myself.

Although these are apparently "warnings", I believe that what is causing them is also breaking other things in a less obvious way for me, so diagnosing this might also fix those...

I think the problem is where $FE_COL_TYPES is defined in: library/OSS-Framework.git/OSS/Controller/Action/Trait/Doctrine2Frontend.php, if that helps...

[barryo]

Are you using the latest version of OSS-Framework? It is defined at:

https://github.com/opensolutions/OSS-Framework/blob/master/OSS/Controller/Action/Trait/Doctrine2Frontend.php#L95

Do a git submodule update in the root directory. If this fails, please provide some of the full error messages (file and line number).

[rowanthorpe]

I had already done a git submodule update, and just did one again now to be sure (already up-to-date), but the problems still remained. I manually edited in the one line you point to in your comment, and every instance of the "YES_NO" warnings disappears 👍 So it seems not to be a code problem, but that git submodule update isn't pulling in the latest version for me (I had already done git pull upstream master beforehand too)...

I had already typed the below diagnostics as requested, but I doubt they are needed now. Anyway, I add them just for reference. In case it's enlightening, I should mention that there are several other bugs I am working through, but didn't mention them here, to not confuse this issue. However they may be indicative of what the underlying version problem is...? If you want me to mention some of them here I will do so in a following comment. Otherwise I will bring them up as new issues.

---

Here are a few example glitches, with appropriate irrelevant bits [SNIP]ed:

• When accessing /customer/list I see at the top 1 occurrence of the following:
  Notice: Undefined index: YES_NO in /root/ixp/application/controllers/CustomerController.php on line 87
• When accessing /user/list I see at the top 28 occurrences of the following (note this is a list of 14 users):
  Notice: Undefined index: YES_NO in /root/ixp/var/templates_c/[SNIP].file.list.phtml.php on line 167
• When accessing /contact-group/list I see at the top 4 occurrences of the following (note this is a list of 4 groups):
  Notice: Undefined index: YES_NO in /root/ixp/var/templates_c/[SNIP].file.list.phtml.php on line 167

etc...

---

[barryo]

I had already done a git submodule update, and just did one again now to be sure (already up-to-date), but the problems still remained. I manually edited in the one line you point to in your comment, and every instance of the "YES_NO" warnings disappears

It looks like you've definitely got a submodule issue. I presume you installed the libraries with git submodule init and git submodule update?

The correct refs for all submodules are currently:

$ git submodule status 
5cb34c1803d9be8c5754883775617626c678cbd5 library/Bootbox.git (v3.1.0-10-g5cb34c1)
80a78be5b09548a21a32dd8bf47933c7fe96fe2b library/Bootstrap-Zend-Framework (heads/master)
4b4b0804ef0da7ad9566e4ebe953e476eb33fb95 library/Minify (heads/master)
be4e32c714d61b5ca1f3ac9a3d53523416b7af97 library/OSS-Framework.git (heads/master)
84f3f33e39f809ccce006bd35d30af4cab2e4179 library/OSS_SNMP.git (remotes/origin/HEAD)
2a36aa4cda560069efffb741eec84c3a8e743d6e library/Smarty (heads/master)
5d79290a2a3051afdcb13504ba8e6f535bc8f0a4 library/Throbber.js.git (heads/master)
00cae46ff71ef1a584dd92c1801dafdf2ccd9374 library/Zend (heads/master)
5aa51fa5bca56db3baf0c9489f072801dd60f5ae library/wiki (heads/master)

The OSS-Framework library for IXP Manager currently points to the head of its master branch. Can you try:

cd library/OSS-Framework.git
git pull

Closing this off as it is not a bug / issue but will continue to respond to any updates.

[rowanthorpe]

I just now followed this sequence to get the submodule up-to-date:

cd library/OSS-Framework.git
git checkout master
git pull

I know that a month or two ago I followed the ChangeLog instructions about transitioning from the old way of including modules to the new one (which definitely included both git submodule init and git submodule update), and hadn't had this problem since then, but a few minutes ago I had the following surprise which pointed me to the problem:

blah:~/ixp# cd library/OSS-Framework.git
blah:~/ixp/library/OSS-Framework.git# git branch
* (no branch)
  master
blah:~/ixp/library/OSS-Framework.git# _

so I guess something unusual behind the scenes reverted it to a non-checked-out state. After the checkout it was fine.

I will now proceed to do the same for all the sub-modules because I suspect that may be the cause of some of my other bugs. If you want me to try anything else to help diagnose how and when that sub-module managed to revert itself to a non-checked-out state let me know. If it helps, the problem seemed to start after the commit which introduced reseller stuff (and several of my remaining warnings are about things like entities having non-existent fields like isReseller, etc)...

[barryo]

so I guess something unusual behind the scenes reverted it to a non-checked-out state

No, this is normal. Submodules are typically detached heads pointing to a specific version / commit.

[rowanthorpe]

Ah. That explains why I had to checkout out all of the sub-modules to git pull them. So do you think it hurts leaving them "checked out" now that they are?

Thanks for your help.

Also, even after git-pulling all the sub-modules' master branches there remain two more Doctrine-esque warnings (which I can find), quoted loosely below:

URL/customer/list  ->  "...Entities\Customer has no field or association called 'isReseller'"
URL/virtual-interface/list  ->  "...Entities\PhysicalInterface has no association called 'PeeringPhysicalInterface'"

Should I:

• Open that as a new Issue
• Try to solve it through our comment-thread here
• Ask for help on mailing-list

?

[barryo]

So do you think it hurts leaving them "checked out" now that they are?

It'll probably bite you in the ass later. You should try and reset your submodules. Possibly by removing them and re-initialising them. Google for the best procedure for this.

there remain two more Doctrine-esque warnings

It looks like you're missing schema changes from the v3.2.0 changelog.

[barryo]

"Try to solve it through our comment-thread here" is fine for now.

[rowanthorpe]

Regarding the "YES_NO" type problem:

I removed and reinitialised all nine submodules (after doing git pull upstream master), and when doing auto-checkout the refs all match the correct refs you mentioned in your earlier comment, except for OSS-Framework.git which is still checking out 0c02f4deaa212c9a53237ccfcc841acaf0bae938. This is from 10 June. A grep for it comes up with:

.git/modules/library/OSS-Framework.git/HEAD:0c02f4deaa212c9a53237ccfcc841acaf0bae938
.git/modules/library/OSS-Framework.git/ORIG_HEAD:0c02f4deaa212c9a53237ccfcc841acaf0bae938

I fixed it manually by:

cd library/OSS-Framework.git
git checkout be4e32c714d61b5ca1f3ac9a3d53523416b7af97

but then that causes this:

cd ../..
git diff

diff --git a/library/OSS-Framework.git b/library/OSS-Framework.git
index 0c02f4d..be4e32c 160000
--- a/library/OSS-Framework.git
+++ b/library/OSS-Framework.git
@@ -1 +1 @@
-Subproject commit 0c02f4deaa212c9a53237ccfcc841acaf0bae938
+Subproject commit be4e32c714d61b5ca1f3ac9a3d53523416b7af97

Regarding the reseller schema problem:

I had followed all CHANGELOG schema change instructions including 3.2.0, but I just reconfirmed anyway by doing describe cust;, describe physicalinterface;, and select peeringpolicy from cust; - and they are all as they should be. So there is something else interfering in the process...

[rowanthorpe]

Following up on the end of my last comment, I removed all the columns, indexes and foreign keys mentioned in the CHANGELOG v3.2.0 instructions, and re-added them as specified, and double-checked that the entries in the config file are as specified there too. The problem still persists, whether reseller.enabled is set to true or false...

From what little I've been able to cram-read about Doctrine since yesterday, I suspect maybe the problem is not with the entries in the database, but in the relevant "entity" definitions for Doctrine? That is just the the wild guess of a desperate Doctrine-n00b though...

[barryo]

Sorry @rowanthorpe - I'm upto my neck right now. Will address this over the weekend or Monday.

[rowanthorpe]

OK, thanks @barryo for letting me know. Will try to post on mailinglist to get more eyes on it in the meantime too.

[barryo]

Will try to post on mailinglist to get more eyes on it in the meantime too.

I suspect only I will be able to help with this particular issue.