Hi,
Am I missing something?
When inserting a row in an empty table, dropdowns don't seem to load any options.
Thanks
Jeremy
Hi @jclutterbuck! Would you mind sharing how your dropdown column is currently configured? I can't seem to reproduce this on my end just yet, but happy to look into this with you!
Perfect! I was able to reproduce and file 
I’ll keep you updated with any fixes - hopefully soon!
Hello, is there any fixes or updates for this issue? I'm having same situation.
Let me check with eng now!
So it looks like this is currently the intended behavior:
“The table is explicitly pulling the dropdown values as unique column values, so when there are no dropdown values, then we wouldn’t expect unique column values either.”
Is this blocking any specific use cases? Let me know and I can pass them back to eng!
This is not a very desirable behaviour. It also doesn't seem to be consistent. When the table has at least one row the drop downs have entries, when the table is empty and you are trying to enter the first row, the dropdowns don't have any entries. That doesn't make sense.
The dropdowns are both being populated by the same query each time, producing the same results (providing it doesn't relate to the table contents, which mine don't). It means I have to add a row without choosing any values from the dropdowns (because you can't). Then save changes. Then edit the dropdowns and save again!!!! This is crazy.
In your message you say "so when there are no dropdown values..." but there should be dropdown values? I would expect "it" to run the queries that populate the dropdown values and for these to be available when you are inserting the first row!
This is blocking ALL my use cases! We are currently using the work around I describe above and I keep promising that eng are going to fix it and to be patient.... but I can't believe you're going to leave it like that?
Thanks
Jeremy
1 Like
Hi @jclutterbuck!
Thank you for taking the time to share your context and thoughts. It's always welcomed and appreciated and does not fall on deaf ears. I passed this back to the PM of the team working on the table and the dropdown column specifically, and will let you know what they say.
Will report back soon,
Victoria
FYI, I found a relavent case here...
It seems the problem resolved at some point of time,
but it happens again. (I'm having this issue on self-hosted retool 2.97.4)
Hello @padam,
I am new to retool and love it. Only this issue is still there in version 2.108.6 on premise (mandatory in our organisation).
Is there any workaround to it
My use case is that there is a specific set of application names (along with additional attributes) which are stored in a database table.
In a retool table component the user needs to choose one of these applications in a Dropdown (Tag column type).
We do this to document in the table containing the tag column which persons have access to which application for accounting purposes (pay per named user).
Therefore the options list of the tag column cannot be empty, even if we document a new user who just purchased his first application from us - which means the table gets its first new row.
By the way: The dropdown options come from a different query than the table data. This input runs automatically when inputs change.
Thanks,
Lars
Hi Lars,
I hope this comment helps.
Hi Victoria,
thanks for the quick answer. I just wanted to write to you because I found the thread you mentioned and got it to work that way.
I am allways eager to learn. I am having trouble to see any use case for the intended behavior you mentioned in October 2022, depending on rows allready in the table. Maybe you could shed some light there.
Yet I see so many use cases to just trust the developer in deciding how to populate the options list. While it seems to me counter intuitive to let the developer decide and then ignore their decision.
Therefore I really hope, this will get fixed in the near future. While there is indeed a workaround it should in my opinion not be the final solution.
Thanks again for your quick help!
Lars
Of course, Lars, and thank you for your feedback here. We definitely plan to address this in our next table iteration coming soon 