Hi there!
I am using various queries in the same Textblaze snippet to obtain different pieces of text from the table.
I would like to have a main variable to choose the table name, so I dont need to add it in every snippet and this way each snippet can work correctly by only changing one parameter.
The idea would be the following
{tablename = "xxx"}// table name
select XX from {=tablename} where YY} //query 1
select ZZ from {=tablename} where ..} //query 2
Only variables or parts of expressions can be dynamic in BSL. So you can do something like:
SELECT x FROM table WHERE y = {="something"}
But you can't do things like:
SELECT x FROM {="table"}
or {="SELECT"} x FROM tables
Without knowing more about your use case, I might suggest adding a field called "Subtable" to your table that could be a text field or a single select field. You could then filter based on that:
SELECT x FROM table WHERE Subtable = {="something"}
Basically we are creating different tables to store the snippet text depending on some predefined dropdowns, basically Country and Reason.
We have the same structure for a lot of tables, having it all in 1 table is not scalable, and we prefer to have it in separate tables and the ideal world would be to be able to name the table and the snippet the same way so it would be the same snippe ttext for each shorcut
SELECT Message FROM {snippet:shortcut} where Country, Reason ...
This way we would not need to do anything in Textblaze to connect the Datablaze content to the snippets, just create them with a snippet shortcut and no need to change anything else from one snippet to another
This isn't supported now, but it might be possible to add. I would like to better understand the scalability concerns with a single table.
Is the concern primarily a performance one where a lot of data in a single table might slow down Data Blaze?
Or is it more of an organizational one where different people will be editing the same table and it would be simpler to give each person their own table to edit so editing conflicts don't occur?
Hi Scott,
A bit of both, but principally it is an organizational concern as you said, having everything in the same table is more risky than having different tables each one with an owner
Have you tried using views to create persistent slices of the data for different people to edit? Going back to my example above, if you had a "Subtable" column, you could have a separate view for each Subtable that matched just that subtable.
We use Data Blaze for our internal Issue tracker and all the engineers have their own view for issues that are assigned to them. For example I have a "Scott's Issues" view showing just the things I am working on.
Would something like that help manage organization coordination?
It's a nice idea, we already built a lot of tables in a different way so now its a little too much work to go back, but I will have a think. Do you confirm that the other suggested solution is not something feasible from your side?