Blockio DB Table in adapter

[Anonymous]

This is an image of the db tables and the wallets, the status does not indicate ‘old' or 'current' so every page view or refresh a new wallet is created.

Attachments:

You must be logged in to view attached files.

[Anonymous]

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 you

[Anonymous]

Alex,

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…

respectfully

Tony Valamontes

[Anonymous]

Hello Alex,

I found the issue, the collation on the status field in the wp_wallet_addr is set to latin1_bin which throws an exception error when there is an attempt to update, by changing it to Utf8_bin that 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 'current'

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 latin1_bin

I am sure if a fix is needed at least we know what is the problem area!

Best regards

Tony

Attachments:

You must be logged in to view attached files.

[alexg]

Hello,

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 SELECT VERSION();?

kind regards

[Anonymous]

Hello Alex,

here are my DB details.

Cheers

Adonis

Attachments:

You must be logged in to view attached files.

[Anonymous]

SELECT VERSION();

VERSION()
5.6.39-cll-lve

[alexg]

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?

[Anonymous]

Hello Alex,

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_bin is for western European languages only I wonder if it is related. Since the issue, I removed the other language features.

I noticed many other enum fields in the wallet tables have utf8_mb4_encode, just an observation wondering why those have utf and this particular one has latin1

Regards

Adonis

Attachments:

You must be logged in to view attached files.

[alexg]

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.

kind regards

[Author]

Posts