[mainnet] New defaults for max- and partial-ops

[xeroc]

The reasoning here is that maintainers and operators don't need to
customize the configuration fiel in order to have the BitShares backend
running in low memory mode. The number 1000 should be sufficient for
most operations (even exchanges) to include all needed operations in the
exchanges' account.

[oxarbitrage]

i like it. i am wondering if we should add a msg in the log that node is starting with this setup or add somewhere in the documentation that this is a reduced node. what do you think?

[abitmore]

I'd highly recommend NOT change the default behavior. Exchange accounts have far more than 1K records. Any changes may break existing business.

[xeroc]

How about this comes with a warning in the release notes that says that exchanges should set the parameters to their liking and or even set track-account?

[pmconrad]

I agree with @abitmore - changing default behaviour is a bad idea and is likely to break existing installations.
I wouldn't mind changing the default config file though, that should affect only new installations.

[oxarbitrage]

i understand both sides. existing business vs potential business lost. existing business is always more important. what do you think about the default config file change @abitmore ?

[abitmore]

I remember the idea about changing default config values has been discussed somewhere, perhaps in the Telegram channel. It's true that it will bring less trouble (but not zero trouble), so I think it's perhaps OK.

[xeroc]

@pmconrad I force pushed a different fix for this issue that stores the stuff in file (if created newly).

Please consider adding this to the new hardfork release right away.

I did testing, it seems to be working as desired.

@oxarbitrage If you don't mind, please also do some testing

[pmconrad]

I'm not a friend of last minute changes, but if Alfredo approves I'm OK with it.

[oxarbitrage]

i like the implementation and it also works good. i think we can also mention this change in the README. merging it, nice job.
in regards to last minute changes to the release let's add this one if possible but no more and start thinking on a next release. Releases that don't have a hardfork should be easier to make and we can make them more often with enough or significant changes from develop to master.

[pmconrad]

After testing I have found that this patch has several downsides:

• the options end up twice in the generated config file, which is confusing
• the new documentation is wrong, it mentions the wrong defaults
• the new values are written to the config file, but they get active only after a restart (!)

[oxarbitrage]

in regards to point 1 i used the pull and the new features didn't ended up twice but only once in the created config file.
in point 2 what is the documentation you are referring to ? the pull only change 1 file and the documentation in there seems correct to me.
i didn't realized of point 3 when testing but if this is the case and a restart is needed then i think it will need to be fixed.

[pmconrad]

This is what was already there:

# Keep only those operations in memory that are related to account history tracking
# partial-operations = 

# Maximum number of operations per account will be kept in memory
# max-ops-per-account = 

...and this is new:

# Keep only those operations in memory that are related to account history tracking (defaults to true)
partial-operations = true

# Maximum number of operations per account will be kept in memory (defaults to 1000)
max-ops-per-account = 1000

Both mentioned defaults are wrong, partial-operations defaults to false and max ops defaults to infinite.

[oxarbitrage]

you are right , i didn't saw it as it was commented, sorry about that. i reverted the merge until this problems are addressed properly.