@Bubble can we please change all references from “Data Type” to “Table”, “Thing Model”, “Document Model”, “Record Model”, “Data Model”, really anything other than “Data Type”.
Data types are what we define our fields as, not the table. 
2 Likes
I thought the correct term was “thing”.
1 Like
How many beginners understand what a Table is?
3 Likes
DISLIKE. I have exactly the opposite opinion, K!
Table is dumb. Data type is rad.
(I will admit: This is about the only Bubble nomenclature choice I agree with.)
1 Like
Why not go the whole hog and call them by their correct term … Relations ?
We then have Tuples which are sets Attributes, and they have names and data types… etc
So help me Codd.
Why not ? Because Bubble’s “database” is not relational.
The problem with “table” is that it implies it is Relational. And Bubble is not really relational, it has object properties.
MongoDb calls these things “Collections” (of Documents) for the same reason. They look like tables but really don’t behave like them.
Whilst I don’t particularly like “Data Type” (which I agree is more int/bool/char) I think Table is more “wrong”.
The way that Bubble handles “Tables” is not like anything else that talks about tables (it loads relationships, doesn’t have keys etc).
A “Thing” is actually a special case of a data type. (“Data type” encompasses both primitive and app-specific data types. A “Thing” is an app-specific [complex] data type.)
For example:
Type: Yes/No (Boolean): primitive data type (not a Thing)
String (text): primitive data type (not a Thing)
Integer (number): primitive data type (not a Thing)
Groovy Dude (no analog in JavaScript): complex data type (*** a Thing! ***): fields “Is Down with the Sickness” (a Boolean), value “yes”; “Username” (a String), value “Your Mom”; “Lucky Number” (an Integer), value “13”
NOTE: A Thing is not necessarily a JavaScript primitive. Witness the “Date Range”. Date Ranges are Bubble primitives, but in JS, they would be 2-element vectors (date range = [start_date, end_date]).
Date Ranges, Numeric Ranges, and Intervals (is that what they are called???) are not Things, but non-JS Bubble primitives.
In the Bubble internals (e.g., plugin editor), “Things” are known as “app types”. They are always complex. They may be singular (representing one instance of the Thing’s type) or lists (representing an array-like object of multiple Things).
I’m not entirely certain if we should call lists of primitives in Bubble, “Things”…
I think it is more that, in Bubble, anything (not “any Thing”, mind you) can be either singular or List-like, primitive (composed of a single, native data type) or complex (composed of multiple native data types AND/OR app-types).
The above is the extent of the Bubble data type universe. You can write a function that retrieves all of these data states and there are no further that need to be accommodated.
So, in summary, we have:
- Singular native data type values. (I call these singular primitives.)
- Array-like multiple native data type values (Lists of primitives)
- Singular complex data type values (singular Things – by which we mean app-type data)
- Array-like multiple complex data type values (Lists of Things)
Here’s a function that I call Annie (for “any thing”, get it?) that, given a Bubble object of any type, retrieves the underlying values:
function annie(thing, field) {
// send annie any thing and she returns its value in the proper way
// argument thing should be a properties object of type 'any thing' - e.g., properties.list1
// optional argument field should be a string representing the name of a field to retrieve from a complex object
var isList, thingvalue, returnValue
function getList(Thing) {return Thing.get(0, Thing.length())}
function mapList(ThingValue, Field) {
var returnValue
if (ThingValue["0"].listProperties().includes(Field)) {
returnValue = ThingValue.map(x => x.get(Field))
} else {returnValue = null}
return returnValue
}
function getSingle(Thing, Field) {
var isComplex, FieldExists, returnValue, a
(typeof(Thing.get) == "function") ? isComplex = true : isComplex = false
isComplex && !(Field == null) ? Thing.listProperties().includes(Field) ? returnValue = Thing.get(Field) : returnValue = null : returnValue = Thing
return returnValue
}
thing.hasOwnProperty("list_api") ? isList = true : isList = false
if (isList) {
thingvalue = getList(thing)
typeof(thingvalue["0"]) == "object" && !(field == null) ? returnValue = mapList(thingvalue, field) : returnValue = thingvalue
return returnValue
}
if (!isList) {
return getSingle(thing, field)
}
} // end annie
So, anyway, data types have nothing to do with the dataBASE. Table is a database term. In Bubble, the database is a given. It is always there. We needn’t worry about it… it’s just storage, right? So all we are concerned with is data and data types. Data types mirror their representational storage state in the database.
We don’t manipulate a table in memory, we manipulate a data type. We do not care about the “table” in Bubble.
(^^^ This is just one way of seeing it, of course, but it’s the correct way. 
If you are more database-centric, you could [sort of] say the same thing from the dataBASE-centric point of view, but honestly I don’t think it’s helpful to noobs or to programmery types. Database stuff is just infrastructure. We do not care how the bits get stored, we care how we can manipulate them. Those manipulations are governed by the types of data we are working with, not by how they are stored somewhere.)
4 Likes
5 Likes
@keith we are concerned with our structure, hence the reason we define it in the “Data Type” tab. You can’t, just on the fly, create a new structure. And I care about how terminilogy is used. Would you call a car a boat, just because someone named it improperly in a manual?
- Bubble uses Postgres
- Postgres IS a relational database*
- They acually call them Tables in their documenation
- They actually discuss changing your Column’s (i.e. field) data type
*I understand it has some NoSQL abilities. Not entirely sure if Bubble is using it schemaless (JSON/JSONB) or not.
We could call it “Document Model”, “Record Model”, “Data Model”, really anything other than “Data Type”.
Bubble used to use Elastic. What it uses is entirely immaterial, as we have no access to the underlying database.
They could migrate to something else, and it would not matter.
But I bet there is a no 1:1 relation (no pun intended) between a Bubble Data Type and a Postgres Table.
Bubble is not a relational database any more than Excel is. It just has sort of rows and columns.
There, I fixed the title and request body.
I just prefer it called something other than “data type”.
Yes. That and “thing”.
1 Like
This is fun! I think it perfectly illustrates the challenge Bubble has as a platform that has to please both coders and non coders. As the latter, I’m cool with “thing”.
5 Likes
I vote for something other than “data type”, too, since it’s very confusing for someone who tries to understand deeper concepts.
It’s nice that Bubble tries to be easy for non-developers and it uses interesting terms like a thing (instead of entities and tables, rows), however it does this in a wrong way.
In professional development, when you do the conceptual design, things are entities (in data world) and/or objects (in object oriented approach), and generalization leads to entity types and classes. Data types usually denote a type of elementary data (string, integer, date). So we have:
DB world: entities --> entity type
OO world: objects --> class
Bubble: things --> data type
In comparison, technologies like Entity Framework (Microsoft) and SQL Alchemy (Python) which try to bridge the gap between different concepts (objects <–> entities) and conceptual and physical design (entity <–> row in a table, attribute <–> column/field in a table) are quite strict and don’t mix these relations. Even the usage of singular and plural is strict in these environments (singular for classes/entity types and plural for table names).
Bubble tries to be nice and when you define a new Bubble data type, you actually define the name of entity type/class and the name of the “table” in the database.
So, how to call it properly? Things type, type of things?
@keith can I please steal Annie 
And btw guys, bubble is a different programming paradigm. Let’s not try to force some other concepts on it.
My non-coder friends understand “Things” (pun intended) than Data type.
Yes I understand your arguments (im a CS major) and agree to some of them but Bubble is a different language. Let’s learn to speak it.
I like my “things”
1 Like
Things of data type
Edit:
I mean, If Bubble is a new paradigm, let’ say that it is a thing oriented language, why bother with mentioning the technical “data”? That’s why I propose type of things or things type.
I have no problems with things, I have problems with data type.
1 Like
Added “Thing Model”.
1 Like
@Kfawcett you seem to want the name to contain “model”.
Try explaining “model” to a non-technical person.
Bubble is a no-code framework targeted mainly at non traditional coders (obviously coders like us are invited to join in the party).
So whatever naming makes easy understanding to non-technical people i’m cool with it.
Dropsource is a no-code framework targeted at traditional app developers. If this discussion was being made on Dropsource forum, i will agree with you 100%. But on bubble i will say no.
I like things the way they are. They might appear wrong because of your technical background but they make for easy understanding for non-technical people.
You want to tell me document model, record model, data model are all easier to understand than data type for a non-technical person?
1 Like
For what its worth, when I teach non-technical folks how to use Bubble, I use the terms “Bucket” to represent table, and the term “thing” for Bubble’s…things.
This is a bucket that only holds users.
Dump all your users in this bucket.
A user is a type of thing that can have a name, an age, etc.
That type of language makes the system more approachable. It drives me crazy as a fairly technical person, but all in the name of accessibility I suppose!
4 Likes
To be frank, I don’t care about the non-techincal person. You could call it a flurbullflabber and it wouldn’t make much of a difference. But, maybe in the long term the non-technical person becomes a techincal person, and maybe they start working with more technical products that actually use proper naming conventions. What then? Now they’ve been poorly educated through their use of Bubble and its odd use of terms like “Data type”.
From a UI pespective, this is a table… use don’t see the data in a JSON string.
From a definition perspective, do a search for “data type” and see what comes up. Here’s wikipedia.
As a non technical person, the hardest part about learning Bubble has been understanding database relationships. The language @andrewgassen uses to describe these relationships resonates with me more so than what @Kfawcett suggests.
My understanding of Bubble’s origin is that they built a platform to strip away the complexities of developing complex web apps. Maybe @Kfawcett doesn’t care about the non-technical person, but thankfully Bubble seems to.
Maybe non-technical people will eventually become technical, but my guess is that most just want to build their software cheap, fast and then focus on their businesses while hiring out the more compex parts to the bubble developer community.
1 Like