Ok this is a bit silly to make a whole forum post about but both the “Get Row by Values” block & “Lookup by Value or Create” block can search by up to 5 values BUT only “Get Row by Values” uses the plural of ‘value’ so “Lookup by Value or Create” should instead be called “Lookup by Values or Create”.
“Update by Value or Create” seems to also have the same mistake, unless this is intentional?
In the add block section the blocks’ description will also need to be updated to reflect the ability to choose multiple values.
Hopefully i haven’t missed a reason why these blocks use the word ‘value’ instead of ‘values’!
I think the original reason was that the plural names existed where there was also a block with the singular name, but some merging later it’s a bit of a mess.
There are plans to redesign the blocks used for interacting with the database. I think that will come with a full re-do of the naming scheme for those blocks. If you keep looking, you’ll find plenty of other inconsistencies. The blocks were built out over time as more functionality was added to databases, so they’re all over the map in terms of supported features, names, etc.
Now that the DB system is largely feature-complete and the access patterns/uis that people like are pretty well-established, we need to create a more general system for performing lookups (ideally with a small handful of mega-blocks with tons of options rather than the current scattered case-by-case collection of blocks).
For lookups, i’m sort of imagining a single “mega” block for doing multi lookups and another for single lookups, a block for getting the number of rows based on a lookup, and maybe a handful of other minor things. But there’s no reason that sorting (for example) should be a separate block, it should just get rolled in as an optional feature alongside the primary lookup block.
Interesting, i’ll try to keep in mind from now on not mention any minor spelling or naming issues.
Hopefully the design for “mega-blocks” goes well. There’s definitely a lot of good cases for combining blocks, like with normal math blocks & float math blocks not needing to be separate but i do have to be honest that i am a bit worried about big differences removing a bit of the comfort i find using inventor. It’s probably not an issue for any others but complete redesigns are usually kinda devastating for me as seeing something i use to rely on, stay happy & feel secure with change is not something i have learnt to deal with well yet.
Sorry if that’s a little too emotional or off-topic or whatever, just felt like i needed to say it somewhere. & i know my opinions have very little importance when deciding changes for inventor but i think it’s good for you to know just in case it’s useful for you at all.
I realize now that I wasn’t entirely clear, but everything I said about redesigning blocks was exclusively to do with the database blocks. There are currently no plans to significantly alter any other large sets of blocks, and certainly not to overhaul all blocks.
A lot of blocks (like math, if statements and advanced conditionals, etc.) have intentionally been kept separate both to decrease backend complexity and make it easier to understand for new users. One feature that has been planned is situation-specific options (e.g. converting if statements to advanced conditionals, or switching between float and non-float math). That should give the best of both worlds, an easy on-ramp and the ability to change things without re-creating the block.
Databases just happen to be an area that I think is best-served by mega blocks. In real usage, you often need to chain a lot of things together (e.g. conditions and sorting and limiting number of results), so having it all bundled into a more complex block seems warranted (it also significantly improves performance if filtering can happen in the DB rather than after the fact with a loop and if statements).
Splitting functions into individual blocks as much as possible works really well for “chainable” code, but quickly becomes an anti-pattern for situations like DBs where you can’t really chain functions together.
There are plans to make block outputs more uniform across the board (some blocks have their block name or other stuff prefixed before every single output, which is unnecessary), but that’s a non-breaking stylistic change.
Also, while we deprecate old blocks alongside or shortly after the release of replacements, the old blocks will continue to work, so you don’t need to worry about re-building your flows. Deprecated blocks just can’t be added in new flows.
In general, we only make major changes when they are deeply needed for one reason or another, and we always try to keep things consistent. The new site rewrite that took place last year, for example, was a response to performance issues and tech debt, but the goal was to make the transition relatively seamless, which I think was accomplished.
We often implement feature suggestions that are requested by one person, so your feedback definitely has an impact.
I always get the Lookups and Gets confused