Start/End captured text is always kept in database (bloat)

[Tomorrow]

I found that the Start/End captured text is kept in database even after user moves to use Regex or Textual.

So it just sits there doing virtually nothing and bloting the database with unnesseseary space wasting.

 

Expected behaviour would be to remove any Start/End matches after users sets up a working regex/textual variable and clicks ok to save app profile.

 

The only way to get rid of this would be to manually remove any web address from the Start/End field prior to setting up regex/textual.

 

If this behaviour is by desing then i would like a reason why and when this would be useful?

Edited July 28, 2011 by Tomorrow

[floele]

Guess the reason is my laziness. I don't see a problem with a few wasted bytes actually.

[Tomorrow]

Ok if you have time in the future then perhaps fix it so that captured text would no longer be preserved?

I guess few excess bytes do no harm but im the kind of guy who likes optimization so i can't really help myself

[Omniferum]

I don't see any need for this behavior to be changed, the only workable implementation would be 'clear on program exit'.

 

But REALLY it is a negligible amount of data, it would only really have performance problems if you had a HUGE .db with something like 100mb worth of pointless data.

 

In the end it really doesn't do any harm, if it bugs you so much you could just export all as .xml and mass replace the 'start/end' xml tags with nothing then re-import. Writing that as a batch script wouldn't be that hard

[Tomorrow]

I don't see any need for this behavior to be changed, the only workable implementation would be 'clear on program exit'.

Initially i was under the impression that the start/end captured text was kept as a backup in case user decided to return from regex/textual but seems it's not.

if it bugs you so much you could just export all as .xml and mass replace the 'start/end' xml tags with nothing then re-import. Writing that as a batch script wouldn't be that hard

Unfortunately this is where i run into unimplemented feature that adds even more manual work for me.

[shawn]

Whether it's an *intended* feature or not, this has saved me quite a bit of time in the past when troubleshooting a regex pattern or on a site that requires alternate methods for different sources. I'd just as soon suffer with the "bloat" of a few extra kb of space in the jobs.db. Unless it's causing actual problems, I don't see how removing the data would help at all.

[Tomorrow]

Hopefully when the export feature is expanded i can do this manually.I already created N++ macro for it.

Im the kind of guy who does these things even of gains are negligible