Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

Radix IoT Website Mango 3 Documentation Website Mango 4 Documentation Website

  • Hello IA,
    First of all, my service is running:
    Mango Core: 3.6.6, Mango API: 3.6.4, Mango UI: 3.6.7, Platform: Centos 7.4.1708, Java Version: 1.8.0_161

    I am trying to get everything in place to perform the latest Mango 3 upgrades. However it is like a line of dominoes. You state that we need to be using MySQL 5.7.8 at a minimum for the JSON data type. Our web server that is running Mango 3 is a Plesk web server which is using MariaDB by default. Up til now this has not been a problem and may not be a problem going forward but I need your advice.

    Plesk only supports upto MariaDB 10.3. I checked if this is equivalent to MySQL 5.7.8 for the JSON data type and this is a quote from the MariaDB site:

    The JSON alias was added in MariaDB 10.2.7. This was done to make it possible to use JSON columns in statement based replication from MySQL to MariaDB and to make it possible for MariaDB to read mysqldumps from MySQL.

    JSON is an alias for LONGTEXT introduced for compatibility reasons with MySQL's JSON data type. MariaDB implements this as a LONGTEXT rather, as the JSON data type contradicts the SQL standard, and MariaDB's benchmarks indicate that performance is at least equivalent.

    In order to ensure that a a valid json document is inserted, the JSON_VALID function can be used as a CHECK constraint. This constraint is automatically included for types using the JSON alias from MariaDB 10.4.3.

    Here is the link to their page for further reference: https://mariadb.com/kb/en/library/json-data-type/

    In your opinion, will the upgrade work with my configuration of MariaDB 10.3? It sounds to me that it would and the differences are only noted for replication and export/imports.

    My second question regarding the Mango 3 upgrade concerns the user email addresses. Our customers sometimes provide the Mango service to their customer. So we may have more than one user name to access a display page. But our customer is the only one I have contact with, so the other users are still referenced by the one customer email contact.

    Would it be possible for me to change the "Unique" attribute in the database with out affecting the operation of Mango 3.7.1?

    I need to know what to expect before I attempt the upgrade.

    Thank you for your time.

    Brian


  • @bg said in Upgrade 3.7.1 Questions:

    My second question regarding the Mango 3 upgrade concerns the user email addresses. Our customers sometimes provide the Mango service to their customer. So we may have more than one user name to access a display page. But our customer is the only one I have contact with, so the other users are still referenced by the one customer email contact.

    Seconded here. I've got sites which have more than one manager but still use the same site email to cover these multiple areas. I know I can manually remove the UNIQUE myself but not sure what this will affect seeing how 3.7 is looking more like what I'll be upgrading to.


  • @BG I am pretty sure there will be no problems with the versions of MariaDB that support JSON columns. To make a long story short we have not tested it with MariaDB but the only place we use the JSON type column so far is in the create table script for the users table so the alias they have will be fine on that statement.

    In the future we may actually create queries that introspect the data in that column but this will likely be for custom modules and not part of the standard Mango application. Also H2 does not support JSON column types so all of our queries basically use that column as a LONGTEXT type currently.


  • @BG and @MattFox for the duplicate User's question the unique constraint was added so that one can reset their password via knowing the email. This constraint is enforced at the SQL table level and also at validation time during saving a User in the code. So removing this constrain from the SQL column will not work.

    Our assumption was that many common platforms have this restriction and we will be integrating this further into authentication process that may involve 2 factor auth and other options so it would not be a problem. I would suggest that you setup an alias for the address. In Gmail this is done via:

    For example, messages sent to the following aliases will all go to janedoe@gmail.com:
    
    janedoe+school@gmail.com
    janedoe+notes@gmail.com
    janedoe+important.emails@gmail.com
    

  • Hello Terry,
    Thank you for you response. This will let me continue with the upgrade. I am sure we can work with the unique email address point. It will just need to make sure I get a separate contact address for each user and explain to the customer it is for password recovery.

    Thank you for your help and I hope you all had a happy Thanksgiving.

    Cheers

    Brian