A data type can be specified both in the Gsheet/Postgres database and in Appsheet itself.
There are fewer data types in Gsheet than in Appsheet.
There are more data types in Postgres than in Appsheet.
What is the correct understanding of the interaction of the database in relation to data types?
Thanks for your help : )
For GSheets used solely as a datasource, it is recommended to define ALL columns as General Text. This avoids issues with certain UNIQUEID() function values getting automatically treated and converted in the data as Exponential Notations. If the value is used as a row key, it can mess up table relationships in the app.
For databases, the type varies some from db to db. The types between the db and AppSheet are independant. I am not certain what would happen if you defined all the types in the db as String/Text. Would it work the same as in GSheets and AppSheet can properly convert to its defined types? I don't know but i suspect it would work.
However, if you have defined column types in the db, then the types from AppSheet must correlate. For example, you can't insert an AppSheet Text column into a db Boolean column. You can't insert a Decimal AppSheet type into a db Integer column. You will get error messages on the attempts to save rows.
For types such Enum, EnumList, Image, File and any other non-corresponding types from AppSheet, I always use String/Text in the db.
There is no documentation I am aware of. So it may require some trial and error.
@Thulium wrote:
Does the data type in appsheet always "win"?
Win? There is no real winning. AppSheet has it's type db has its type. The two must be compatible such that AppSheet can accept the value from the DB into the AppSheet table AND vice-versa.
@Thulium wrote:
Is there a synchronization of data types between database and appsheet?
If yes: in one direction or in both?
No.
@Thulium wrote:
What happens if the data type is different? Does Appsheet then warn and suggest a change to the data type?
If the types defined are not compatible there will be an error message that the AppSheet row cannot be saved. It is up to the App Creator to understand which system needs adjusted.
@Thulium wrote:
Is it best practice to specify no data type at all in the data base (in Gsheets "none") or the most universal one (in Postgres)?
There is no such thing as "no type" in GSheets or a database. In GSheets, used only as a datasource, its best to define all columns as General Text. In a db, for at least some protection against garbage being inserted into the column, I recommend defining specific types where possible. The others would be String/Text.
@Thulium wrote:
Where can I find official information on this topic?
Some common DB's have documentation. PostgresSQL is one - see link below. But because AppSheet can support dozens of cloud-based and in-house databases through common protocol, they all could use their own set of column data types. So not all possible databases have documentation.
Use data from PostgresSQL
I hope this helps!
Thank you for your detailed answer : )
@WillowMobileSys wrote:There is no such thing as "no type" in GSheets or a database.
Until now, I assumed that it is absolutely essential that the data types of the appsheet and the database are "compatible" with each other for each column - so that an app really works stably and reliably.
Since each database only has a limited number of data types (one to two dozen), I assumed that Appsheet has documented exactly internally if the data types are not compatible for a column.
I thought Appsheet would then issue a warning and give a hint on what to do manually. (Not only when trying to save a new data record.) Or better, if this is technically possible: Appsheet suggests changing the data type in Appsheet or the database. The user only has to confirm.
If I have understood you correctly, there is nothing like this. The user alone must know which types are compatible and set them up manually.
In my opinion, this is not good for the reliability of apps. I would never have expected something so essential to be "left to chance".
@WillowMobileSys wrote:
"There is no such thing as "no type" in GSheets"
That's why I spoke of data type "none".
@Thulium wrote:
If I have understood you correctly, there is nothing like this. The user alone must know which types are compatible and set them up manually.
No, there isn't. As I said it is nearly impossible to perform such a feature for all of the possible databases out there that AppSheet can support. New databases/potential datasources are created frequently. It would be difficult for a suggestion to be made since it relies heavily on your intent.
Additionally, they do report an error. I don't remember the context of that error but it does enlightens you that there is a type mismatch. It's an error that usually comes from the db and then reported in AppSheet.
I did provide you the link to their documentation for PostgresSQL. In that doc they do outline the Type compatibility. There are other docs for their most supported db's.
@Thulium wrote:
In my opinion, this is not good for the reliability of apps. I would never have expected something so essential to be "left to chance".
This is not an AppSheet thing. I am not aware of any platform that does what you are saying. Maybe if they support only specific datasources but then it would be conscientiously programmed into that platform . Even programming languages such as C#, iOS/Swift, Java,etc, have to contend with this problem when sending retrieving data to/from the databases/datasources. Variables in the app must be matched up to data types in the columns. Standardization would be nice but there are so many different languages and databases!!
@Thulium wrote:
That's why I spoke of data type "none".
I understand now and have not seen that before. Tables in Sheets are relatively new and I don't use sheets that way. Just a quick read on the "None" type...it is a column that allows a mix of data across the rows. That presently is not allowed in any database nor any application. While it could be supported, it would make the column usage extremely complicated.
Thank you very much for your answer 🙂
Let's look at the 2 cases separately:
1 Appsheet (a software from Google) plus Gsheet (a software from Google)
2 Appsheet (a software from Google) plus Postgres (FOSS)
Regarding 1:
Appsheet offers 33 data types:
Address
app
ChangeCounter
ChangeLocation
ChangeTimestamp
Color
Date
DateTime
Decimal
Drawing
Duration
E-mail
Enum
EnumList
File
image
LatLong v LongText
name
Number
Percent
Phone
Price
progress
Ref
show
Signature
text
Thumbnails
Time
Url
video
XY
Yes/No
Gsheet offers 11:
Number
Percent
Currency
text
Date
Date time
Time
Drop down
Checkbox
Smart chips
None
I still can't believe that it is technically impossible or difficult for Google to automatically issue warnings when different types of data could cause problems. This looks like a very manageable and solvable task to me.
The goal is high-level:
Stability of an app and its database.
@Thulium wrote:
I still can't believe that it is technically impossible
I didn't say it was technically impossible. I said it was "nearly impossible" due to the shear scale of work required due to the number of databases that can be supported and the frequent revisions needed when new types are added or a new datasource pops up.
This is not a big enough issue to warrant the effort required. However, the AppSheet team might feel differently than me. I would suggest to submit a Feature Idea to put the concept on AppSheet's radar.
User | Count |
---|---|
16 | |
15 | |
4 | |
3 | |
2 |