dashed-slug.net › Forums › block.io Cloud Wallet Adapter extension support › Blockio DB Table in adapter
Tagged: blockio, db schema, deposit address, latin1
- This topic has 9 replies, 2 voices, and was last updated 6 years, 2 months ago by alexg.
-
AuthorPosts
-
July 21, 2018 at 1:08 pm #3802AnonymousInactive
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.July 21, 2018 at 1:10 pm #3804AnonymousInactiveOn 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
July 21, 2018 at 1:17 pm #3805AnonymousInactiveAlex,
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
July 21, 2018 at 5:12 pm #3807AnonymousInactiveHello Alex,
I found the issue, the collation on the status field in the
wp_wallet_addr
is set tolatin1_bin
which throws an exception error when there is an attempt to update, by changing it toUtf8_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.July 23, 2018 at 7:01 am #3822alexgKeymasterHello,
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 meSELECT VERSION();
?kind regards
July 23, 2018 at 12:13 pm #3854AnonymousInactiveHello Alex,
here are my DB details.
Cheers
Adonis
Attachments:
You must be logged in to view attached files.July 23, 2018 at 12:16 pm #3856AnonymousInactiveSELECT VERSION();
VERSION()
5.6.39-cll-lveJuly 24, 2018 at 9:27 am #3865alexgKeymasterThanks, 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 #3873AnonymousInactiveHello 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 thelatin1_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 haveutf8_mb4_encode
, just an observation wondering why those haveutf
and this particular one haslatin1
Regards
Adonis
Attachments:
You must be logged in to view attached files.July 25, 2018 at 7:58 am #3880alexgKeymasterThe 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
-
AuthorPosts
- You must be logged in to reply to this topic.