Changing code to load bank data from SQLite DB

[Prasun Kumar]

>
> > Also, there are many methods which deal solely with textfile reading
> > such as dataValidStartDate(), dataValidEndDate(), isDataValidForDate(),
> > find_closest_datafile to name a few.
>
> >  bool isDataValidForDate(std::time_t date) const;
> >
>  > /** Returns true if a bankdata file valid for the given date is
>  > * available, otherwise false.
>  >  *
>  >  * Whether this file has already been loaded has to be queried
>  >  * separately through isDataValidForDate().
>  >  *
>  >  * This function was introduced in ktoblzcheck-1.15.
>    */
> This and the other methods are part of the public api and should not be
> removed as clients may depends on them.
>

If these methods are to exist, should the support of bankdata "text" files
be kept enabled in the code?
Specifically, should the constructor retain the call to
init_datefile_list() even while reading through a SQLite DB?

Thanks.
Prasun


On Sun, 14 Jun 2020 at 01:35, Ralf Habacker <ralf.habacker at freenet.de>
wrote:

> Am 13.06.20 um 06:52 schrieb Prasun Kumar:
> > Hi mentors,
> > I have tested the SQLite database to implement
> > AccountNumberCheck::findbank() and it worked successfully. Now I'm
> > ready to change the present code.
> > So how should I make these commits? Should I replace the current code
> > by commenting them out
> No  need for that as changes are recorded in git log
>
> or should I remove them altogether?
>
> yes, see above
>
> > Also, there are many methods which deal solely with textfile reading
> > such as dataValidStartDate(), dataValidEndDate(), isDataValidForDate(),
> > find_closest_datafile to name a few.
>
> >  bool isDataValidForDate(std::time_t date) const;
> >
>  > /** Returns true if a bankdata file valid for the given date is
>  > * available, otherwise false.
>  >  *
>  >  * Whether this file has already been loaded has to be queried
>  >  * separately through isDataValidForDate().
>  >  *
>  >  * This function was introduced in ktoblzcheck-1.15.
>    */
> This and the other methods are part of the public api and should not be
> removed as clients may depends on them.
>
> > To make the commits small, I would be making a commit for each method
> > change.
> yes, looks good.
>
> Regards
>
> Ralf
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-finance-apps/attachments/20200620/5ae35991/attachment.htm>