July 21, 2018 at 1:08 pm #3802
This is an image of the db tables and the wallets, the status does not indicate ‘
'current'so every page view or refresh a new wallet is created.July 21, 2018 at 1:10 pm #3804
On follow up I did a clean install and tried a different version of the wallet adaptor what is why you see a need to update.
Thank youJuly 21, 2018 at 1:17 pm #3805
I want to say that your product is a great addon for crypto payments when I can across this set of modules I knew I found something I want to use, so when we in the group decided to deploy it, my job is to find a way to make it fail… we want to use this product in complex services and be responsible for other people’s money, you have to take every step and opportunity to provide a service that has a reduced mitigated risk.
Thank you for your time and effort…
Tony ValamontesJuly 21, 2018 at 5:12 pm #3807
I found the issue, the collation on the status field in the
wp_wallet_addris set to
latin1_binwhich throws an exception error when there is an attempt to update, by changing it to
Utf8_binthat allow the change of the status.
When I refresh I do not see any new addresses created I only see in the profile the wallet with the status set to
Versions I used were Wallet 3.5.5 and Latest Blockio adaptor 2.2.3, at this point the only thing left to do is check to see if the update to the 3.5.6 with change any the collation back to
I am sure if a fix is needed at least we know what is the problem area!
TonyJuly 23, 2018 at 7:01 am #3822
The error you report is not an exception but a database error and I do not think it indicates that your DB cannot handle this charset/collation.
Please keep in mind that coin adapters are an abstraction/encapsulation of crypto wallets, and they do not touch the database directly.
The collation is set to latin1 to match the character set which is also latin1 for fields that do not require Unicode. This includes coin symbols, addresses and transaction IDs.
Latin1, as you know, has one byte wide characters and this saves space. If four bytes were used as you suggest, this would cause problems with the size of some table indexes. This is why latin1 is used. It is unlikely that your database cannot handle this basic collation and charset as it is the most basic one – essentially ASCII.
Instead, it is possible that you have run on some of the block.io service limits with a free account and this is probably why you do not get new addresses. At this point in time if I were you I would prefer to use the CoinPayments adapter which has no such limitations.
In any case the SQL
UPDATE wp_wallets_adds SET status = 'current' where id = 1;should not generate an error, and it does not on my machine. This is curious. Which DB are you using? Can you show me
kind regardsJuly 23, 2018 at 12:13 pm #3854
here are my DB details.
AdonisJuly 23, 2018 at 12:16 pm #3856
5.6.39-cll-lveJuly 24, 2018 at 9:27 am #3865
Thanks, your DB version seems pretty standard.
I am still not sure how the enum column could cause this DB error, although I have searched the web and SO extensively.
Can you confirm that 1. the error still occurs and 2. that it gets resolved when the only change you do, is to change the collation on the column to
Utf8_bin?July 24, 2018 at 3:14 pm #3873
The error does not occur because I changed the latin1_bin to
utf8_bin, I am not sure if its coincidence but the error showed up after I tried t install a multi-pack language to the site. I know the
latin1_binis for western European languages only I wonder if it is related. Since the issue, I removed the other language features.
I noticed many other
enumfields in the wallet tables have
utf8_mb4_encode, just an observation wondering why those have
utfand this particular one has
AdonisJuly 25, 2018 at 7:58 am #3880
The reason for the discrepancy is that when the addresses table is first created, it is created with a table-wide default encoding of latin1, since it does not need to contain any Unicode data. The dbdelta() function that WordPress provides does not handle encodings, and therefore I have some manual alter table queries in there to ensure that some columns do not generate indexes that are too large for some old versions of MySQL. The encoding for enum types is not really important, as the possible values are enumerated and therefore take up fixed space when indexed.
Bottom line is, I am currently unable to verify that changing to a different encoding would solve a reproducible issue.
But if another encoding or collation works for you, then go ahead and use it. You should not have any problems doing so.
You must be logged in to reply to this topic.