Data truncated for column 'version'

[ggeerraalldd]

I installed the module in local/modules and ran a migration to set up my mySQL munkireport database tables.
After adding the module to my .env, I did a client installation via curl on my computer to test out the reporting.
During the first munkireport-runner process I got this error:

Server info: starting: reportdata
Server An error occurred while processing: \Mosyle_business_processor
Server Error: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'version' at row 1 (SQL: insert into mosyle_business (serial_number, version, org_name, attempt_date, success_date, location_enabled) values (ABC12DE3F4, 6.12.17, ORG, 1680116506.214574, 1680116508.364317, 0))

The migration sets up 'version' as an integer. Is that going to work with '6.12.17' or does it need to be a string?

[precursorca]

Hmm. I don’t remember seeing that error. But it is working for me so far. I will see what. I can find out.

…

--- Alex Narvey ***@***.***

On Apr 5, 2023, at 1:59 PM, Gerald Mcdonald ***@***.***> wrote: I installed the module in local/modules and ran a migration to set up my mySQL munkireport database tables. After adding the module to my .env, I did a client installation via curl on my computer to test out the reporting. During the first munkireport-runner process I got this error: Server info: starting: reportdata Server An error occurred while processing: \Mosyle_business_processor Server Error: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'version' at row 1 (SQL: insert into mosyle_business (serial_number, version, org_name, attempt_date, success_date, location_enabled) values (ABC12DE3F4, 6.12.17, ORG, 1680116506.214574, 1680116508.364317, 0)) The migration sets up 'version' as an integer. Is that going to work with '6.12.17' or does it need to be a string? — Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEG7VEWFELUPH2M3VY5QZVTW7W6KRANCNFSM6AAAAAAWUOP5DA>. You are receiving this because you are subscribed to this thread.

[ggeerraalldd]

Thanks!

I just ran munkireport-runner and quickly edited the cache/mosyle_business.txt results to change "6.12.17" to "61217" and the data uploaded to the server. When I ran mr-runner again normally , it failed on version like before. It seems like the decimals are the source of my problem.

macOS 12.6.4, munkireport 5.7.1, mySQL 8.3.0, php 7.4.30

[precursorca]

The only difference is I am using SQLite

…

--- Alex Narvey ***@***.***

On Apr 5, 2023, at 3:20 PM, Gerald Mcdonald ***@***.***> wrote: Thanks! I just ran munkireport-runner and quickly edited the cache/mosyle_business.txt results to change "6.12.17" to "61217" and the data uploaded to the server. When I ran mr-runner again normally , it failed on version like before. It seems like the decimals are the source of my problem. macOS 12.6.4, munkireport 5.7.1, mySQL 8.3.0, php 7.4.30 <https://user-images.githubusercontent.com/24395097/230197357-6b14b4f0-0395-466a-96c3-1ad05700e445.png> — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEG7VEXJF4D3CMCURHJ3J7TW7XHXVANCNFSM6AAAAAAWUOP5DA>. You are receiving this because you commented.

[ggeerraalldd]

I made a new migration that used $table->dropColumn('version') and $table->string('version')->nullable(); to recreate the version column, and that fixed it in my instance.

It took a couple attempts, so don't know if it was a combination of 2 migrations, or just the last one I tried that worked. I'm brand new to the please make-migration game.

I can continue playing around with it, especially since I'm beta testing MR 5.8 on another computer, and since that db isn't in production can try more things (or start over).

[precursorca]

I also have it on both a 5.7 and a 5.8.But I did the migration form the web page dashboard in both cases.---Precursor Systemshttp://www.precursor.ca- Apple Authorized Value Added Reseller- Certified member of the Apple Consultants NetworkOn Apr 5, 2023, at 5:21 PM, Gerald Mcdonald ***@***.***> wrote: I made a new migration that used $table->dropColumn('version') and $table->string('version')->nullable(); to recreate the version column, and that fixed it in my instance. It took a couple attempts, so don't know if it was a combination of 2 migrations, or just the last one I tried that worked. I'm brand new to the please make-migration game. I can continue playing around with it, especially since I'm beta testing MR 5.8 on another computer, and since that db isn't in production can try more things (or start over). —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[ggeerraalldd]

Tested on MR5.8 with SQLite last night, and did not have the version error.
This morning I set up mySQL 8.0.32/PHP8.2, created munkireport db and ran migrations.
Configured a test client and connected, and it failed the same way

Server An error occurred while processing: \Mosyle_business_processor
Server Error: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'version' at row 1 (Connection: default, SQL: insert into `mosyle_business` (`serial_number`, `version`, `org_name`, `attempt_date`, `success_date`, `location_enabled`) values (A1BCD23EF4GH, 6.12.17, ORG, 1680702326.924118, 1680702327.880424, 0))
Server info: starting: mosyle_business

Deleted the munkireport db, changed your migration to use

        $table->string('version')->nullable();

I created a new munkireport db in mySQL, reran migrations and had the client check in. This time it worked.

So mySQL and sqlite are treating the data differently. 6.12.17 is definitely not an integer, but sqlite accepts it anyway.

I found this when searching about INTEGER usage in sqlite, which explains why:

Introduction to SQLite data types

If you come from other database systems such as MySQL and PostgreSQL, you notice that they use static typing. It means when you declare a column with a specific data type, that column can store only data of the declared data type.

Different from other database systems, SQLite uses dynamic type system. In other words, a value stored in a column determines its data type, not the column’s data type.

[precursorca]

Yes you are quite right. I was just looking at that and will update it later today. The Mosyle module is not everything I hoped for as the settings file is for the app and only gets filled in if the user actually launches the app. Which it turns out most of my users have not. The script could tell the app to launch one time if the settings are not filled in but launching the app the first time requests bluetooth permissions so I will have make a profile to send out in MDM before doing that so that users will not be freaked out by the warning which probably pops up. I will continue to experiment. Thank you so much for you comments and your work on this. Very much appreciated.

…

--- Alex Narvey ***@***.***

On Apr 6, 2023, at 9:35 AM, Gerald Mcdonald ***@***.***> wrote: Tested on MR5.8 with SQLite last night, and did not have the version error. This morning I set up mySQL 8.0.32/PHP8.2, created munkireport db and ran migrations. Configured a test client and connected, and it failed the same way Server An error occurred while processing: \Mosyle_business_processor Server Error: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'version' at row 1 (Connection: default, SQL: insert into `mosyle_business` (`serial_number`, `version`, `org_name`, `attempt_date`, `success_date`, `location_enabled`) values (A1BCD23EF4GH, 6.12.17, ORG, 1680702326.924118, 1680702327.880424, 0)) Server info: starting: mosyle_business Deleted the munkireport db, changed your migration to use $table->string('version')->nullable(); I created a new munkireport db in mySQL, reran migrations and had the client check in. This time it worked. So mySQL and sqlite are treating the data differently. 6.12.17 is definitely not an integer, but sqlite accepts it anyway. I found this when searching about INTEGER usage in sqlite, which explains why: Introduction to SQLite data types If you come from other database systems such as MySQL and PostgreSQL, you notice that they use static typing. It means when you declare a column with a specific data type, that column can store only data of the declared data type. Different from other database systems, SQLite uses dynamic type system. In other words, a value stored in a column determines its data type, not the column’s data type. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEG7VEWWXDVTXW44ORT75BLW73ICNANCNFSM6AAAAAAWUOP5DA>. You are receiving this because you commented.

[precursorca]

I made the changes to GitHub.

…

--- Alex Narvey ***@***.***

On Apr 6, 2023, at 9:46 AM, Alex Narvey ***@***.***> wrote: Yes you are quite right. I was just looking at that and will update it later today. The Mosyle module is not everything I hoped for as the settings file is for the app and only gets filled in if the user actually launches the app. Which it turns out most of my users have not. The script could tell the app to launch one time if the settings are not filled in but launching the app the first time requests bluetooth permissions so I will have make a profile to send out in MDM before doing that so that users will not be freaked out by the warning which probably pops up. I will continue to experiment. Thank you so much for you comments and your work on this. Very much appreciated. --- Alex Narvey ***@***.*** > On Apr 6, 2023, at 9:35 AM, Gerald Mcdonald ***@***.***> wrote: > > > Tested on MR5.8 with SQLite last night, and did not have the version error. > This morning I set up mySQL 8.0.32/PHP8.2, created munkireport db and ran migrations. > Configured a test client and connected, and it failed the same way > > Server An error occurred while processing: \Mosyle_business_processor > Server Error: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'version' at row 1 (Connection: default, SQL: insert into `mosyle_business` (`serial_number`, `version`, `org_name`, `attempt_date`, `success_date`, `location_enabled`) values (A1BCD23EF4GH, 6.12.17, ORG, 1680702326.924118, 1680702327.880424, 0)) > Server info: starting: mosyle_business > Deleted the munkireport db, changed your migration to use > > $table->string('version')->nullable(); > I created a new munkireport db in mySQL, reran migrations and had the client check in. This time it worked. > > So mySQL and sqlite are treating the data differently. 6.12.17 is definitely not an integer, but sqlite accepts it anyway. > > I found this when searching about INTEGER usage in sqlite, which explains why: > > Introduction to SQLite data types > > If you come from other database systems such as MySQL and PostgreSQL, you notice that they use static typing. It means when you declare a column with a specific data type, that column can store only data of the declared data type. > > Different from other database systems, SQLite uses dynamic type system. In other words, a value stored in a column determines its data type, not the column’s data type. > > — > Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEG7VEWWXDVTXW44ORT75BLW73ICNANCNFSM6AAAAAAWUOP5DA>. > You are receiving this because you commented. >

[ggeerraalldd]

I'm also not sure of its utility in our org. We don't use Self-Service at all and rely on munkitools for patch management and custom scripts and configurations.

Anyway, it was more enjoyable puzzling this out than installing homebrew and signing PHP for a new server...

[precursorca]

LOL Yes I use munki and munkireport a lot. Just wanted to know more about the Mosyle agent being up to date and syncing properly. So far this is just telling me about the Mosyle Self-Service app and not the agent itself.

…

--- Alex Narvey ***@***.***

On Apr 6, 2023, at 10:33 AM, Gerald Mcdonald ***@***.***> wrote: I'm also not sure of its utility in our org. We don't use Self-Service at all and rely on munkitools for patch management and custom scripts and configurations. Anyway, it was more enjoyable puzzling this out than installing homebrew and signing PHP for a new server... — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEG7VER4BQACOWHRRDU4XNLW73O3DANCNFSM6AAAAAAWUOP5DA>. You are receiving this because you commented.