Uniqueness of rows

Baserow Help
1

Is it possible to have unique numbers/letters in one row such that it doesnt reappear in other rows?

1 Like
2

Hello! On the screenshot I highlighted where the row unique ID is located. This record will always be unique, because the number increases +1 even when you delete records.

Image
Image1201×346 115 KB

3

Hi,

I see that but I want to stop recurring serial numbers in different rows and its different to what you have said.

4

Would you mind elaborating a bit more on what you want to do, it’s a bit unclear? Do you want to have some sort of unique constraint/validation, where you can can’t create a row with a certain value if it already exists?

5

Yes thats pretty much what im going for, if there already exists a cell with ABC there cant be any rows in that column with that same value.

6

That’s currently not possible with Baserow. It’s called a unique constraint and we’re not going to implement that anytime soon. If we want to implement this feature with the right UX, it’s going to be a lot of work to build it and we’re currently focusing on other features.

7

Acknowledged. I’m new around here and happily building away on top of several tables in a database now. It sounds like handling field uniqueness is the province of the application in Baserow world, so I’ll note that and handle as needed. I’m looking for any general advice on how to approach wanting to use fields other than the id for row lookups. A couple of reasons that first come to mind:

  1. It is common in publishing to use “slug” fields as a primary lookup key even if it isn’t the primary key on the table, with the assumption the field is constrained to be unique. You may be familiar that Django’s generic views can fetch objects by slug only. A corollary feature to this is allowing any unique field to be used in row lookups…
  2. Having the row ID in the URL may not be desirable for several reasons for some sites

Has anyone dealt with maintaining their own unique constraint for Baserow fields?

8

About a year ago, there was a merge request to implement a unique constraint in Baserow. This one was closed because of the reason I explained above, but maybe it could somehow be of help to you. You can find the changes here: [Unique Columns] add support for unique columns (!272) ¡ Merge requests ¡ Bram Wiepjes / baserow ¡ GitLab.

1 Like
9

Just found this old post. It is absurd that this unique column constraints has not been fixed. This is a fundamental aspect of relational databases and Baserow is built on postgres, which offers this out of the box! Just created a new topic about this. Hopefully, Baserow will listen and reopen that feature request.

1 Like
10

Yes, this is completely absurd that this ‘issue’ has not been fixed.

I am saying ‘issue’ in quote because Baserow team (composed of database specialists) is being deliberately deceptive about this, and rely on user politeness to not pointing it out.

Each table is supposed to have a ‘primary field’, which purpose is to ‘uniquely identify each entry’ or ‘acts as its unique identifier’ according to their own doc (Primary field). The use of word is obviously meant to remind us of a ‘primary key’. And then when you ask on this forum how come the feature does not actually performed as advertised, you are told that ‘WOW this is a NEW FEATURE and not a priority ftm sorry’…

If baserow had been upfront about their low-code database app inability to offer custom unique id in order to, I don’t know, not duplicate data, I would have chosen another solution.

11

@jplr8922 this feature is prioritized and in the Baserow roadmap, which means it’s a highly important one. We aim to release it this quarter. :slightly_smiling_face: