Some of my current ideas

[holroy]

Hi there, I'm planning to implement some ideas of mine in the very near future, and in no particular order they are:

• A new Obsidian command Dataview: Rebuild current view which simply calls that function of the obsidian api to workaround the bugs related to queries not refreshing » Add workaround to refresh issue of #1752 #2237
• New query command: slice(), Slice and dice #2176, which would work similar to the ordinary javascript slice command, allowing for various lists to be sliced and diced » Adds #2176 slice() #2238
• New query command: zip(array1, array2, ... ), which would join together the values from the different arrays into one common array. This could be used for joining start and end arrays of work periods for example, before being split and calculated into the actual workhours. This would counter, at the users risk, the missing compound objects within a block. Possibly also add a izip() which in addition would simply add the index of the array values into the common array, so that we're free to do index filtering or similar when handling arrays
• New query command: srandom(), a seeded random function could be used to sort any list in a random order. Seeded so that it's possible to get it to receive the same list given the same seed. This latter part would enable us to get a random sequence based upon a seed which might be linked to a timestamp, so that the random sequence could stay fixed within a given day/hour/...
• I'm also contemplating on the following ideas:
• Implementing the set of keys(), values() and entries() as query commands for better handling of compound objects
• Adding defined() to the query commands to be able to distinguish between defined fields and field which are just empty
• Extending the sort() command to allow for picking out a field to sort on if its a list of objects
• Uncertain on how to do this one, but I would like some option to not show the children of lists/tasks queries, and possibly to filter out the children. I'm thinking along the lines of adding a SUB <filter-expression> to the query language, where it would receive each child and it would do an actual change on the children list. Another option, but I think that's harder to implement would be to allow a FLATTEN clause to mutate its result into .children (or other variables)
• Also a little uncertain: Add some possibility to add a class to a DQL query (like described in some thread which I can't remember just now)
• If @RyotaUshio doesn't come through, try to fix the issues of Inline fields not rendered correctly in reading view #2216, since that seriously cripples my listings of tasks and lists with the inline fields just repeating themselves

Well, that's my ideas for now. Do you like them? Is there something else we should aim to add before the next release, whenever that will be?

I'm hoping to do most of these within a week or so... :-D

[holroy]

Added #2252 for the srandom() function. Coding takes time, but I like the outcome of this method.

[holroy]

After a little debate, this is ready to be replaced by #2272 which implements a hash() function instead of a full blown seeded random generator.