Hi, On Mittwoch, 21. Juni 2017 12:49:09 CEST Łukasz Wojniłowicz wrote:
> Hi Cristian, > > Please test latest master branch because I think your issues are fixed. > > Referring to order of transactions in report after transaction modification, > it was sorting, that was to blame. > I changed it intentionally while implementing multicurrency totals, but it > broke your use case, so I returned old sorting. > First tests show that my use case isn't broken and yours work too, but I > would expect troubles with multicurrency totals anyways somewhere in > future. > > During the research, I found a bug (not critical) that transaction IDs > written to .kmy file aren't being red from the file. Transaction IDs are > assigned through function during KMM start and stay so till application > quits. The assignment is according to date. When one changes date, the > assigned ID won't change till KMM starts anew. The assigned ID is being > written to .kmy file, but won't be red, because KMM will assign new IDs at > start. Well, sort of. For XML based files, this ID is reassigned during file load. This is not a bug, but based on a design decision. to keep transaction ids small in amount and regain those that were deleted. It should not hurt at all to keep the values that are stored in the file. This can be changed in MyMoneyXmlContentHandler::endElement() if it helps to solve your issues. One thing is critical: you should not base application logic on any of the IDs of KMyMoney. At one point, we might change them to something completely different which is not in any particular order (GUID). I did not use them as debugging and following is much harder and hence used the system as it is today. I know, that in some places (ID assignment in general) the current code relies on the layout of the IDs (one letter, n digits) but that is only in a very few places in the engine code (mymoney subdirectory) and not in the application. There is an additional piece of information which is used for accessing a transaction and sorting per post-date and is obtained via MyMoneyTransaction::uniqueSortKey() when the transaction is added to the ledger in MyMoneySeqAccessMgr::addTransaction() or modified (since parts of the sortkey may change). When loading from file, the creation of that key happens in MyMoneyXmlContentHandler::endElement() where the transaction loaded. If a transaction does not have an id (it is empty) it is part of a schedule and the re-assignment won't happen. This is sort key is used during the lifetime of the application and not stored on file. So in fact, you have the following indirection: m_transactionKeys[transactionid] = sortkey; m_transactionList[sortkey] = transaction This way, iterating over m_transactionList is always in post-date order as the sortkey is based on MyMoneyTransaction::postDate() (see MyMoneyTransaction::uniqueSortKey()). > That was the reason why your reports showed correctly after restart. I am not sure if I completely understand what your multi currency report problem has to do with transaction IDs. -- Regards Thomas Baumgart https://www.telegram.org/ Telegram, the better whats app ------------------------------------------------------------- "I know, a 'real Linux geek' doesn't walk around the wall: He bangs his head against it until it tumbles down!" -- wobo on FLUG ml -------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part.
