Documentation: if|table, priority of search patterns #2181
Comments
|
Is that something you would like to help with ? I gave if tables a serious try recently but I found them difficult to understand and not very widely useful. I'd be more inclined to remove them, personally. |
simonmichael
added
docs
Not really. It is just a request to improve documentation. I agree that if|tables are not easy to work with and could be confusing. Other way to define "else" rule, it has to be the first entry in the table (it has the lowest priority and matches any record): |
|
I appreciate the issue and example, thanks. I still don't find it too compelling. I think this feature needs someone to champion it and do the work of making it more usable, otherwise it's for the chop sooner or later.
|
|
I don't use iftables, but
This is similar to one of the motivations for adding rewrite rules -- I wanted to warp the credit card repayment postings to the start of the billing period, so I regex-match the year-month bit, and hard-code a different day. However this only works for my card where the start of the billing period is in the same month as the statement. I have one credit card where this holds and one where it doesn't. To address the other, I was thinking we might need some kind of date manipulation support in rewrite rules. Although I wouldn't like to implement them! In the meantime, I have an ugly series of 12 if statements which match the month portion like this The reason I mention this, I had hoped to try and tackle it with if tables but found that they don't help this problem at all. |
I think I wrote it originally and I use it extensively, and I would be very sad to see it go. @simonmichael , what kind of work (besides documentation) do you envision it needing? Semantically, an "if table" of N rows behaves exactly the same as would N "if" statements, one per table row - it just occupies about 4x less lines (and significantly fewer characters, and removes the repetition, and ...), so I would argue that it is not significantly more confusing than N if statements Edit: I have 2200 lines worth of "if tables" and while it is not hard to write a generator that would convert them into if statements to be included in the csv rules file, I would rather avoid doing this if possible |
|
Actually, looking at the documentation, I would argue that the behavior is documented (emphasis in the below is mine): An if table like the above is interpreted as follows: |
|
Ahaha, hello @adept. I didn't remember. There you are. Sorry to threaten your feature. :) You're the first person I've found relying on it. Could you help us understand how/for what you use it ? In my experience (multiple tries) it is extremely non-intuitive for "normal people" at present. The work needed is at least handling UX/doc requests like this one. Also I haven't found a good use case of my own where it helped, yet. It needs more examples/motivation. I had vague ideas of how variations of it could be useful to more people. But I'll wait to hear what you tell us. |
No worries, I knew you would not shoot to kill without warning :) My primary use-case is this: for CSV import rules, I usually have account1 fixed in the rules file, and then based on the CSV line, I assign account2, and potentially a comment. Over time, you accumulate lots of rules that look roughly the same: Another way to present them would be: This is way more compact, and it is also dead easy to add new rules -- maybe even in automated fashion: https://github.com/adept/full-fledged-hledger/wiki/Sorting-unknowns |
|
Sorry, forgot one more thing. I have lots of csv files and a build system to convert them to journals. Tabular machine-readable nature of the (majority of) the rules means that I could easily check which rules affect which input files. Then, when rules change, i can rebuild just the affected journals: https://github.com/adept/full-fledged-hledger/wiki/Speeding-up |
|
I miss a possibility to disable a row in if|table, like to comment it. And I miss comments to explain why some row is in if|table; this can improve readability of rules. Something like this: |
|
Comment lines in the table body seem sensible, I made a PR for this. Comments inside field assignments feel more controversial (plus, I don't immediately see how to implement them AND allow user to use ";" or "#" in, say, "comment" field assignments in the table), so I haven't done them. |
|
I am using if tables. Anyone who is using https://github.com/adept/full-fledged-hledger is using if tables. My HLedger setup is based on adept's full fledge ledger. |
This is just a request to update documentation for CSV import, command if|table
IF table can have several patterns that match record. Important point is that
hledgeruses THE LATEST pattern that matches the expression. Information describing this behavior should be added to the documentation.Example, records in CSV file don't have full date, only year and month. We want to translate that information in the way that payment is done in the last day of the month, like 2020-04 -> 2024-04-30. This is not straight forward task, months have different number of days, between 28 and 31 and February can have 28 or 29 days.
NOTE: The payment is done on the first day of the next month but I do not see any "easy" way to code such translation without coding rule for each month, like 2020-04 -> 2020-05-01 or 2020-12 -> 2021-01-01. That is why I use the last day of the month, it is easier to code...
The translation of date from Y-M format to Y-M-D is coded with if|table; note that rules matching any February are before rules those defines years where February has 29 days. Rule with higher priority has to be added to the end of the "if table".
IF|table cannot have "else" rule but such rule can be defined with default value that could be overwritten with a rule in the table.
Run it:
The text was updated successfully, but these errors were encountered: