In D13242#272596, @tbaumgart wrote:

Works for me so far. Here's what I have tested:

1. Loading XML file
2. Make a change
3. Save as XML file
4. Quit and restart
5. Load the XML file saved in step 3
6. Verify that payeeidentifier are still present
7. Verify that online job information is still present
   
   This looks good so far.
8. Load XML file
9. Save as database
10. Quit and restart (loads the database)
11. Verify that payeeidentifier are still present
12. Verify that online job information is still present
    
    Except step 5. everything seems to work. I have to mention, that 5. also does not work on master, so it is not this patch which breaks the feature. Nevertheless, this is a bug that needs to be fixed before we can be sure that this change works as expected with databases.

In general looks OK to me. Did some casual testing (saving/loading).

Works for me so far. Here's what I have tested:

Added some missing methods.

I'm a little confused - was this committed or abandoned?

Nobody has been removed in models directory. It's well maintained directory :)

I've committed it as there is no more feedback regarding missing authors.

So far, I have not seen any problem while working with an XML based file. I don't use the DB backend. For me this looks OK. Maybe, you can take care of those two comments areas before you land this change.

In D13020#269157, @tbaumgart wrote:

In D13020#269117, @wojnilowicz wrote:

In D13020#269078, @tbaumgart wrote:

After fixing some DB related bugs in master, I applied this patch again. Saving a DB to SQLITE still fails, but now I get a different error on the console:

Failed to save onlineJob "O000001" Reson: Could not load sqlStoragePlugin 'org.kmymoney.creditTransfer.sepa.sqlStoragePlugin', (error: No service matching the requirements was found) /home/thb/devel/kmymoney/kmymoney/plugins/sql/mymoneystoragesql_p.h:2662

One line for each one of them, and I have a few.

I've fixed

No service matching the requirements was found

but saving still fails and it's not part of this patch, as it has failed before in the same spot as before the patch.

It's not the saving part, but it seems to be the reading part. After saving an XML file as database I see the online transaction data in the kmmSepaOrders table using an external browser. But opening the database leaves the view empty. The data of the kmmCostCenter table is not saved. The data is in the XML file and the table is empty, but that is not related to this patch.

In D13020#269117, @wojnilowicz wrote:

In D13020#269078, @tbaumgart wrote:

After fixing some DB related bugs in master, I applied this patch again. Saving a DB to SQLITE still fails, but now I get a different error on the console:

Failed to save onlineJob "O000001" Reson: Could not load sqlStoragePlugin 'org.kmymoney.creditTransfer.sepa.sqlStoragePlugin', (error: No service matching the requirements was found) /home/thb/devel/kmymoney/kmymoney/plugins/sql/mymoneystoragesql_p.h:2662

One line for each one of them, and I have a few.

I've fixed

No service matching the requirements was found

but saving still fails and it's not part of this patch, as it has failed before in the same spot as before the patch.

In D13020#269078, @tbaumgart wrote:

After fixing some DB related bugs in master, I applied this patch again. Saving a DB to SQLITE still fails, but now I get a different error on the console:

Failed to save onlineJob "O000001" Reson: Could not load sqlStoragePlugin 'org.kmymoney.creditTransfer.sepa.sqlStoragePlugin', (error: No service matching the requirements was found) /home/thb/devel/kmymoney/kmymoney/plugins/sql/mymoneystoragesql_p.h:2662

One line for each one of them, and I have a few.

After fixing some DB related bugs in master, I applied this patch again. Saving a DB to SQLITE still fails, but now I get a different error on the console:

I tested this on on top of c5a3c44b2a341d6 and was able to compile and install it successfully. I was unable to do any further tests, because creating a database from an existing file fails consistently (which may not be related to this change - I did not check). So here's what I do

createFromSqlDatabase methods are now moved to SQL storage plugin as well, so the only core area of KMM that requires SQL is ibanbicdata.

Are you seriously questioning that people in distributed teams worked on software before the internet? I certainly remember passing sourcecode around on floppy disks and CDs myself. This was a pain in the neck and I'm sort of jealous of you if you didn't have to go through that. Just because you didn't does not mean noone did, though.

In D12979#265515, @wojnilowicz wrote:

So how did those changes travelled to the repository? Through conventional post in an envelope on a diskette? :)

Are you seriously questioning that people in distributed teams worked on software before the internet? I certainly remember passing sourcecode around on floppy disks and CDs myself. This was a pain in the neck and I'm sort of jealous of you if you didn't have to go through that. Just because you didn't does not mean noone did, though.

Hmm, isn't that logic flawed even for people who did have CVS though? Couldn't someone have sent patches (and therefore be a legit contributor) to a file before getting CVS access and never have touched the file again later on?

In D12979#265252, @wojnilowicz wrote:

[...] That's the "metric" (as you called it) you can apply only to names who had an account in CVS. They've contributed directly through CVS, so they can be identified by CVS logs. [...]

1. add Darren Gould name in every file he contributed,
2. include contributions before 2001-03-07,
3. include authors that were only in .h files and not in .cpp files.

While your assumption that people without traces in cvs or on the mailing list may not be valid authors is probably not the worst metric someone could come up with it is, in the end, still just speculation.

As this is not a really good forum for this type of discussion, I hope I can be sufficiently brief here, and perhaps we can continue the discussion on the dev mailing list.

Another problematic example is kmymoney/mymoney/mymoneyinstitution.cpp where you removed Michael Edwardes. The first comment for this file in CVS is by Thomas and says "[...] renamed MyMoneyBank to MyMoneyInstitution, also all references[...]".
When you look into the 0.3.1 release on the sourceforge page that Jack linked, you'll find that the original mymoneybank.cpp does only list Michael in the header - he seems to be a legit contributor to this file if not the initial author.
This also kind of disproves your "Let's be real, if someone had an account in cvs for commiting code, then he wouldn't ask someone else for commiting it for them. You can see proofs of any work on cvs stats, mailing list and logs, that I linked above." argument in D12836.

In D12979#265130, @wojnilowicz wrote:

The topic seems a little bit hot and I think because of some misconceptions going on here:

1. people added their names to the headers either by themselves or asking someone else to add it for them,
2. people contributed to the files,

As this is not a really good forum for this type of discussion, I hope I can be sufficiently brief here, and perhaps we can continue the discussion on the dev mailing list.

NOTE: I think it is important to have this discussion, but I do not intend for it to block or delay committing these changes. Even if there is eventual agreement for a different handling of author names, it can be handled with a separate commit at that time.

Wow. Don't you think that "kicking somebody off the project" seems a little harsh? In the end, those people claimed their authorship through adding their names to the headers (and that's what -when push comes to shove- really matters), not through comments on a mailing list or cvs commits. To me, removing someone who did potentially contribute (and, honestly speaking, why would someone add him/herself to the headers of the source files if they didn't?) in any form (technically this could have been verbally expressed advice, review or anything that happened offline before checking the code in) is (in lack of better words) morally questionable and, at the very least, just rude. How would you feel if in a year or two someone removes your name arguing that he or she doesn't see you as a valid author/contributor because of some kind of self defined metric (cvs commits, in this case)? In your opinion - what is the improvement (to the code, the application, the project, or anything) or gain resulting from removing those people?

Wow. Don't you think that "kicking somebody off the project" seems a little harsh? In the end, those people claimed their authorship through adding their names to the headers (and that's what -when push comes to shove- really matters), not through comments on a mailing list or cvs commits. To me, removing someone who did potentially contribute (and, honestly speaking, why would someone add him/herself to the headers of the source files if they didn't?) in any form (technically this could have been verbally expressed advice, review or anything that happened offline before checking the code in) is (in lack of better words) morally questionable and, at the very least, just rude. How would you feel if in a year or two someone removes your name arguing that he or she doesn't see you as a valid author/contributor because of some kind of self defined metric (cvs commits, in this case)? In your opinion - what is the improvement (to the code, the application, the project, or anything) or gain resulting from removing those people?

I'm committing this as there is no real reason why I shouldn't do that. I don't want to be involved in a theoretical discussion about a theoretical author and his theoretical contribution. Everything is logged in git and cvs. You can commit there in somebody's name and not yourself.
Any substantial postal contributions are theoretical. Any collateral/mutual/parallel/team contribution just seem not right from the stand of authorship.

In D12808#263743, @christiand wrote:

In D12808#262242, @wojnilowicz wrote:

[…] so what's left is:

1. Untranslated excepctions, as normal user doesn't need to understand exceptions, only developers do,

Here I agree with you. Unfortunately, they are used to inform the user anyway (violating this concept) and thus should be kept translated. In the long run this could be replaced by separate classes.

In D12808#262242, @wojnilowicz wrote:

[…] so what's left is:

1. Untranslated excepctions, as normal user doesn't need to understand exceptions, only developers do,

In D12836#262929, @ostroffjh wrote:

Thomas: I consider losing track of someone (simply disappearing from the scene) different from someone dying. However, I agree that is a different issue from what to do with listing email addresses which are not know active, or even known to no longer be valid.

Łukasz: No, I do not have anyone particular in mind either. However, lack of proof that someone did contribute (due to lack of checking into the source repository) is not proof that he did not contribute. Removing someone from the list of authors is essentially making a claim that person did not contribute to that file. I would not object to moving those names to the bottom of the list, with something like "Early contributions by:"

Thomas: I consider losing track of someone (simply disappearing from the scene) different from someone dying. However, I agree that is a different issue from what to do with listing email addresses which are not know active, or even known to no longer be valid.

In D12836#261500, @ostroffjh wrote:

From the original summary:

Moreover, there are some names in the headers, which have not event touched the file, so it's false authorship. Those names has been removed. List of the names to remove has been taken from CVS (http://kmymoney2.cvs.sourceforge.net/) and git logs.

I am extremely concerned by this. If two people worked together on writing/editing some code, and only one of them checked the final copy into cvs/git, then the other name would not show up in the logs, but only in the header. Unless you have better proof they did not contribute, I would not remove names.

In D12808#261471, @christiand wrote:

In D12808#261399, @wojnilowicz wrote:

I understand that it allows us to distinguish between exceptions but who should handle exceptions that we can't handle?
I think it's our duty to do that, because some library throws it at us, because we acted on it in some way, so we are here to blame, so we should handle it.
Just passing exception beyond our application doesn't make the issue go away.
In my opinion, we should know every exception that is being thrown at us, so that we can be aware, even if we aren't prepared from the outset for it.

I understand you point of view and in most cases I agree with you. However, from many years of code development I learned that handling all exceptions right is just not feasible. Also it adds a lot of code for cases which nearly never happen. Just think about std::bad_alloc, I am sure we never handle that even though every new can throw it. Even if you want to handle it, how do you want to do that? In these cases it is way easier and justifiable just to quit and restart the program. Additionally I want to highlight that this patch does not handle all exceptions, it just pretends to do so — by catching them. Imaging for any reason no more memory can be allocated, then a std::bad_alloc is thrown. I am sure that the first one is catched but just to provoke a second one which is not handled anymore. Also, for good reasons C++11 deprecated the throws(…) construct (which required to know all exception possibly thrown) — it just never worked in real life.

The same probably holds true for Ace Jones. He disappeared without a trace from one day to the next. Some email addresses might even not be valid anymore.

Separate question on header style: Is there a suggestion for dealing with a deceased author? (Allan Anderson) There is not much point in listing an email address in this case.

From the original summary:

Moreover, there are some names in the headers, which have not event touched the file, so it's false authorship. Those names has been removed. List of the names to remove has been taken from CVS (http://kmymoney2.cvs.sourceforge.net/) and git logs.

I am extremely concerned by this. If two people worked together on writing/editing some code, and only one of them checked the final copy into cvs/git, then the other name would not show up in the logs, but only in the header. Unless you have better proof they did not contribute, I would not remove names.

I like this very much!

In D12808#261399, @wojnilowicz wrote:

I understand that it allows us to distinguish between exceptions but who should handle exceptions that we can't handle?
I think it's our duty to do that, because some library throws it at us, because we acted on it in some way, so we are here to blame, so we should handle it.
Just passing exception beyond our application doesn't make the issue go away.
In my opinion, we should know every exception that is being thrown at us, so that we can be aware, even if we aren't prepared from the outset for it.

This is the first part of the patch. If nobody has anything against it. I will prepare subsequent parts to change remaining headers.

In D12808#261353, @christiand wrote:

Hi Łukasz,

actually I liked the separate class for exception handling. It allows to distinguish between issues within KMyMoney and outside of it. Typically we do not/cannot handle things like std::bad_alloc so the “missing” catch is desired. Also there is some code which expects this behavior (I think the onlineJob casting stuff), just replacing everything is dangerous. You could inherit MyMoneyException from std::runtime_error. Then we can knowingly change the catches where it is useful and safe.

I do not think that the reduced amount to compile is a benefit here. Reading these two sentences will for sure require more time than all users of KMyMoney together can possibly save.

Compiles for me. Seems to work also. No further checking done.

In D12758#261361, @christiand wrote:

Why was it disabled in the first place if the fix is that easy?

Compiles for me. I did not do any further checks.

Why was it disabled in the first place if the fix is that easy?

actually I liked the separate class for exception handling. It allows to distinguish between issues within KMyMoney and outside of it. Typically we do not/cannot handle things like std::bad_alloc so the “missing” catch is desired. Also there is some code which expects this behavior (I think the onlineJob casting stuff), just replacing everything is dangerous. You could inherit MyMoneyException from std::runtime_error. Then we can knowingly change the catches where it is useful and safe.

In D12759#261339, @christiand wrote:

I am not into this code, so I can only give general advice.

I am not into this code, so I can only give general advice.

Looks OK to me now. I have only tested KBanking imports which were good.

Looks OK otherwise to me. Please land once changed.

Yes, that looks better, but

In D12829#261207, @tbaumgart wrote:

What is the pre-requisite for this patch? I can't apply it to current master.

thb@thb-nb:~/devel/kmymoney (master)$ arc patch D12829
 INFO  Base commit is not in local repository; trying to fetch.
Created and checked out branch arcpatch-D12829.
Checking patch kmymoney/plugins/statementinterface.h...
Checking patch kmymoney/plugins/ofx/import/ofximporter.h...
Checking patch kmymoney/plugins/ofx/import/ofximporter.cpp...
Checking patch kmymoney/plugins/kbanking/kbanking.cpp...
Checking patch kmymoney/plugins/interfaces/kmmstatementinterface.h...
error: while searching for:
  /**
    * This method imports a MyMoneyStatement into the engine
    */
  bool import(const MyMoneyStatement& s, bool silent = false) final override;

  /**
   * This method returns the account for a given @a key - @a value pair.

error: patch failed: kmymoney/plugins/interfaces/kmmstatementinterface.h:51
Checking patch kmymoney/plugins/interfaces/kmmstatementinterface.cpp...
Applied patch kmymoney/plugins/statementinterface.h cleanly.
Applied patch kmymoney/plugins/ofx/import/ofximporter.h cleanly.
Applied patch kmymoney/plugins/ofx/import/ofximporter.cpp cleanly.
Applied patch kmymoney/plugins/kbanking/kbanking.cpp cleanly.
Applying patch kmymoney/plugins/interfaces/kmmstatementinterface.h with 1 reject...
Rejected hunk #1.
Applied patch kmymoney/plugins/interfaces/kmmstatementinterface.cpp cleanly.

 Patch Failed! 
Usage Exception: Unable to apply patch!

What is the pre-requisite for this patch? I can't apply it to current master.

Thanks Łukasz! (Sorry for the late reply)

Fixed some more warnings.

Hi ocoole,

What a mess... I give up.

This now compiles, but when I do the following

I think d-pointer is not possible (too many objects and pointer passing). Those templates with exception throwing were redundant. This payeeIdentifier thing looks like overengineered. I think we need to simplify it and integrate maybe into kmm_mymoney.

Fails for me with