| --- Log opened Mon Oct 26 00:00:23 2020 |
| 00:02 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has joined #code |
| 00:02 | | mode/#code [+o himi] by ChanServ |
| 00:33 | < Yossarian> | ToxicFrog: it's not in the repo but i should see if there is a more aggressive repo and put it on the list |
| 00:35 | < Yossarian> | Reiver: not sure, i thought that that particular bug was fixed, openxcom works with tftd doesn't it? it might have compatibility issues (oxc) with TFTDextender |
| 00:36 | < Yossarian> | but I was just messing around trying to get oXc to compile before running a series of errands and doing things |
| 00:37 | <&ToxicFrog> | openxcom will work with tftd. it will not work with tftdx because that patches the original DOS binary and openxcom obviously does not use the original binary, but I believe it also incorporates most or all of the settings that xcomx/tftdx had. |
| 00:38 | < Yossarian> | i'm starting to get the coding itch again, been depressed for a very long time... I just - I wish I had my textbooks or a tablet/convertible with two screens, I saw something on hackaday with customized keyboard for tablet on the reverse. 3d printed and custom keycaps, seemed very ergonomic |
| 00:41 | < Yossarian> | but in the interim to maybe making something like that, I can get a 2006-10 tablet that would probably satisfy the need to be able to have something to read digital texts with |
| 00:43 | < Yossarian> | yeah tftdx i wanted to say patches the binary but i wasn't sure, it makes sense why they're not compatible |
| 01:35 | <@sshine> | okay, I'm modelling a payment system. there are two entities: Invoices and Payments. |
| 01:35 | <@sshine> | sorry, there's a third entity: Payer. |
| 01:35 | <@sshine> | both an Invoice and a Payment refer to a Payer and some amount. |
| 01:36 | <@sshine> | you can find the balance of a Payer by taking the difference of all their payments and all their invoices. |
| 01:36 | <@sshine> | the first task of doing that without fetching all payments and invoices I solve by performing this subtraction in SQL. |
| 01:38 | <@sshine> | the next task is to restructure the database such that two particular queries are possible in an efficient way: .getInvoicesForPayment(paymentId) -> [Invoice], and .getPaymentsForInvoice(invoiceId) -> [Payment] |
| 01:39 | <@sshine> | efficient means "without fetching all invoices and payments", so same criterion as finding the balance efficiently, but different implications. |
| 01:39 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has quit [[NS] Quit: Leaving] |
| 01:39 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has joined #code |
| 01:39 | | mode/#code [+ao VirusJTG VirusJTG] by ChanServ |
| 01:39 | <@sshine> | what I came up with, which is partly inspired by what Vorn mentioned a couple of days ago, is to have an InvoiceReceipt and a PaymentReceipt. |
| 01:42 | <@sshine> | so assuming the slate is clean for paymentId 1, a history of first getting invoiced $350 and then making four payments to cover it might look like: Invoice(1, $350), Payment(1, $100), Payment(1, $100), Payment(1, $100), Payment(1, $100). |
| 01:43 | <@sshine> | sorry, I should add datetimes explicitly. |
| 01:44 | <@sshine> | and that the idea is that receipts contain an accumulating balance |
| 01:45 | <@sshine> | so I = Invoice, P = Payment, IR = InvoiceReceipt, PR = PaymentReceipt... I(1, $350, T1), P(1, $100, T2), P(1, $100, T3), P(1, $100, T4), P(1, $100, T5) is turned into I(1, $350, T1), IR(1, -$350, T1), P(1, $100, T2), PR(1, -$250, T2), ..., P(1, $100, +$50, T5). |
| 01:47 | <@sshine> | whoops. typing a bit fast. that was meant to be P(1, $100, T5), PR(1, +$50, T5). I suppose I could embed the running balance rather than make them separate entities, but that's a side thought. |
| 01:49 | <@sshine> | given this layout, if I want to answer the question .getPaymentsForInvoice(invoiceId = 1) (being the I(1, $50, T1) one), I should get back each of the four payments because coverage is defined as having debt and having that payment partly or fully cover it. how do I know when to no longer count payments as partly or fully covering an invoice? when the running balance changes sign. |
| 01:49 | <@sshine> | so I have to not only keep track of the running balance but also calculate the sign change, either by recording it or by finding the previous receipt. |
| 01:49 | <@sshine> | I can conceptually defend this approach. |
| 01:51 | <@sshine> | my question is this: since both Invoice and Payment affect the balance, where do I store the running balance? my initial idea (or rather, my interpretation of Vorn's suggestion) was to keep a BalanceReport entity that has a number that is either positive or negative. |
| 01:54 | <@sshine> | but say the payment history for a Payer is -$250, +$100, +$100, +$100, and both the invoice and the three payments result in another BalanceReport, and the BalanceReport also keeps track of sign change, then... does BalanceReport keep two columns, one if it was triggered by an Invoice and one if it was triggered by a Payment? this seems to break normalization. |
| 01:56 | <@sshine> | so this is my initial modelling: BalanceReport(balanceReportId, invoiceId, paymentId, balance, isSignFlipped) |
| 01:58 | <@sshine> | and -$250 +$100 +$100 +$100 would trigger the following BalanceReports (BRs): BR(1,1,NULL,-$250,True), BR(2,NULL,1,-$150,False), BR(3,NULL,2,-$50,False), BR(4,NULL,3,+$50,True) |
| 02:00 | <@sshine> | wait, no. |
| 02:01 | <@sshine> | asking for .getPaymentsForInvoice(invoiceId = 1) would involve 1) get BR where invoiceId = 1, 2) get next BR where isSignFlipped is opposite (balanceReportId = 4)... I now come to realize that in the scenario where a second Invoice is made before the first one is covered, keeping track of the sign flipping won't be sufficient. |
| 02:04 | <@sshine> | so say I have a PaymentReceipt table, it should have an invoiceId column that refers to the invoice it's paying off. so if an Invoice entity keeps track of whether it's been squared (closed), then creating a Payment can check what the oldest not-closed Invoice is and refer to that. and then add some cruft logic when a payment exceeds one invoice and moves on to the next... |
| 02:07 | | * sshine draws the tables so far, bbiab. |
| 02:54 | | Degi [Degi@Nightstar-dgol94.pool.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 02:55 | | Degi [Degi@Nightstar-2qq11p.dyn.telefonica.de] has joined #code |
| 02:59 | | Pink [uid208117@Nightstar-h2b233.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
| 04:09 | | Vorntastic [uid293981@Nightstar-h2b233.irccloud.com] has joined #code |
| 04:09 | | mode/#code [+qo Vorntastic Vorntastic] by ChanServ |
| 04:42 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has quit [Connection closed] |
| 04:42 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has joined #code |
| 04:42 | | mode/#code [+ao VirusJTG VirusJTG] by ChanServ |
| 06:02 | | celticminstrel [celticminst@Nightstar-r1cum5.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 06:58 | <@sshine> | geez. turns out what I really want is a simple `invoice_payment` (`invoiceId`, `paymentId`, `balance`, `settledAt`) table with (`invoiceId`, `paymentId`) as primary key. sorts everything. |
| 07:21 | | gnolam [lenin@Nightstar-ik80lk.priv.bahnhof.se] has joined #code |
| 07:21 | | mode/#code [+o gnolam] by ChanServ |
| 07:38 | | Kindamoody[zZz] is now known as Kindamoody |
| 09:47 | | catalyst [catalyst@Nightstar-v6lb30.cable.virginm.net] has quit [Ping timeout: 121 seconds] |
| 09:51 | | catalyst [catalyst@Nightstar-v6lb30.cable.virginm.net] has joined #code |
| 10:56 | | Kindamoody is now known as Kindamoody|afk |
| 12:36 | | celticminstrel [celticminst@Nightstar-r1cum5.dsl.bell.ca] has joined #code |
| 12:36 | | mode/#code [+o celticminstrel] by ChanServ |
| 12:44 | | celticminstrel [celticminst@Nightstar-r1cum5.dsl.bell.ca] has left #code [] |
| 12:45 | | celticminstrel [celticminst@Nightstar-r1cum5.dsl.bell.ca] has joined #code |
| 12:45 | | mode/#code [+o celticminstrel] by ChanServ |
| 14:06 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 14:06 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 15:38 | | Vorntastic [uid293981@Nightstar-h2b233.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
| 15:53 | | Kindamoody|afk is now known as Kindamoody |
| 17:09 | | Emmy [Emmy@Nightstar-l49opt.fixed.kpn.net] has joined #code |
| 19:47 | | gnolam [lenin@Nightstar-ik80lk.priv.bahnhof.se] has quit [Server shutdown] |
| 19:47 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has quit [Server shutdown] |
| 19:47 | | Degi [Degi@Nightstar-2qq11p.dyn.telefonica.de] has quit [Server shutdown] |
| 19:47 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has quit [Server shutdown] |
| 19:47 | | Syloq [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Server shutdown] |
| --- Log closed Mon Oct 26 19:47:35 2020 |
| --- Log opened Mon Oct 26 19:52:43 2020 |
| 19:52 | | TheWatcher [chris@GlobalOperator.Nightstar.Net] has joined #code |
| 19:52 | | Irssi: #code: Total of 30 nicks [17 ops, 0 halfops, 0 voices, 13 normal] |
| 19:52 | | mode/#code [+o TheWatcher] by ChanServ |
| 19:52 | | Irssi: Join to #code was synced in 15 secs |
| --- Log closed Mon Oct 26 20:02:25 2020 |
| --- Log opened Mon Oct 26 20:07:32 2020 |
| 20:07 | | TheWatcher [chris@GlobalOperator.Nightstar.Net] has joined #code |
| 20:07 | | Irssi: #code: Total of 30 nicks [17 ops, 0 halfops, 0 voices, 13 normal] |
| 20:07 | | mode/#code [+o TheWatcher] by ChanServ |
| 20:07 | | Irssi: Join to #code was synced in 15 secs |
| 20:51 | | Tamber [tamber@furryhelix.co.uk] has joined #code |
| 20:51 | | mode/#code [+o Tamber] by ChanServ |
| 22:21 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 22:29 | < Yossarian> | How goes the coding? |
| 22:42 | | Kindamoody is now known as Kindamoody[zZz] |
| 23:19 | | Emmy [Emmy@Nightstar-l49opt.fixed.kpn.net] has quit [Ping timeout: 121 seconds] |
| --- Log closed Tue Oct 27 00:00:25 2020 |