pH7-Social-Dating-CMS: Mutual Friends Error
We have this error in the database error log table and I don’t really understand why this has been done in this way???
I have changed identifing info like the username, ip and table name.
{"Time":"07-06-2020 08:30:22","IP":"127.0.0.0","UserAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/127.0.0.1 Safari\/537.36","UrlPag":"https:\/\/domain.com\/mutual-friends\/username","Query":"mutual-friends\/username","Message":"SQLSTATE[22003]: Numeric value out of range: 1690 BIGINT UNSIGNED value is out of range in '`<subquery2>`.`profileId` + `table_prefix`.`f`.`friendId` - 1740'","Level":"22003","File":"\/home\/domain\/_protected\/app\/system\/core\/models\/FriendCoreModel.php","Line":88}
if you json_decode this for easier veiwing you get this…
"Time":"07-06-2020 08:30:22",
"IP":"127.0.0.0",
"UserAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/127.0.0.1 Safari\/537.36",
"UrlPag":"https:\/\/domain.com\/mutual-friends\/username",
"Query":"mutual-friends\/username",
"Message":"SQLSTATE[22003]: Numeric value out of range: 1690 BIGINT UNSIGNED value is out of range in '`<subquery2>`.`profileId` + `table_prefix`.`f`.`friendId` - 1740'",
"Level":"22003",
"File":"\/home\/domain\/_protected\/app\/system\/core\/models\/FriendCoreModel.php",
"Line":88
The offending function in model looks like this…
public function get($iIdProfileId, $iFriendId = null, $mLooking, $bCount, $sOrderBy, $iSort, $iOffset, $iLimit)
{
$bCount = (bool)$bCount;
$iOffset = (int)$iOffset;
$iLimit = (int)$iLimit;
$mLooking = trim($mLooking);
$bDigitSearch = ctype_digit($mLooking);
$sSqlSelect = !$bCount ? '(f.profileId + f.friendId - :profileId) AS fdId, f.*, m.username, m.firstName, m.sex' : 'COUNT(f.friendId)';
$sSqlLimit = !$bCount ? 'LIMIT :offset, :limit' : '';
$sSqlWhere = '(f.profileId = :profileId OR f.friendId = :profileId)';
if (!empty($iFriendId)) {
$sSqlWhere = 'f.profileId IN
(SELECT * FROM (SELECT (m.profileId)
FROM ' . Db::prefix(DbTableName::MEMBER_FRIEND) . ' AS m
WHERE (m.friendId IN (:profileId, :friendId))
UNION ALL
SELECT (f.friendId) FROM ' . Db::prefix(DbTableName::MEMBER_FRIEND) . ' AS f
WHERE (f.profileId IN (:profileId, :friendId))) AS fd
GROUP BY fd.profileId HAVING COUNT(fd.profileId) > 1)';
}
$sSqlSearchWhere = '(m.username LIKE :looking OR m.firstName LIKE :looking OR m.lastName LIKE :looking OR m.email LIKE :looking)';
if ($bDigitSearch) {
$sSqlSearchWhere = '(m.profileId = :profileId AND f.friendId= :profileId) OR (m.profileId = :friendId OR f.friendId= :friendId)';
}
$sSqlOrder = SearchCoreModel::order($sOrderBy, $iSort);
$rStmt = Db::getInstance()->prepare(
'SELECT ' . $sSqlSelect . ' FROM' . Db::prefix(DbTableName::MEMBER_FRIEND) . 'AS f INNER JOIN' . Db::prefix(DbTableName::MEMBER) .
'AS m ON m.profileId = (f.profileId + f.friendId - :profileId) WHERE m.ban = 0 AND ' . $sSqlWhere . ' AND ' . $sSqlSearchWhere .
$sSqlOrder . $sSqlLimit
);
$rStmt->bindValue(':profileId', $iIdProfileId, PDO::PARAM_INT);
if ($bDigitSearch) {
$rStmt->bindValue(':looking', $mLooking, PDO::PARAM_INT);
} else {
$rStmt->bindValue(':looking', '%' . $mLooking . '%', PDO::PARAM_STR);
}
if (!empty($iFriendId)) {
$rStmt->bindValue(':friendId', $iFriendId, PDO::PARAM_INT);
}
if (!$bCount) {
$rStmt->bindParam(':offset', $iOffset, PDO::PARAM_INT);
$rStmt->bindParam(':limit', $iLimit, PDO::PARAM_INT);
}
$rStmt->execute();
if (!$bCount) {
$mData = $rStmt->fetchAll(PDO::FETCH_OBJ);
} else {
$mData = (int)$rStmt->fetchColumn();
}
Db::free($rStmt);
return $mData;
}
So we take f.profileId add it to f.friendId then subtract the profile Id :profileId to me thias makes no sense and not sure how to solve this problem?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 30 (22 by maintainers)
@Undefined-Variables We are getting farhter and further away from the date it got opened ? Was that the kind of comments you’d expect ! LOL 😉
I will make a graph in UML regarding how the process work. And from there maybe we could do some refactoring. Because now it’s somewhat misleading.
No problem, thank you 😃