RE: [GT] Trouble with backtest.pl and beancounter

["Weigert, Thomas" <weigert AT mst.edu>]

The true reason, I believe, is different for this problem...

Somebody wanted to provide support for multiple files for a given
market, with different timeframes per file. E.g., IBM.day.csv,
IBM.week.csv, IBM.30min.csv, etc.

The data access routines were changed to work as follows:

1. try to load the market, e.g., IBM.csv, if no data is found,
2. try to load the market for IBM.<timeframe>.csv, where <timeframe>
   Is the current timeframe; if no data is found,
3. move to the next shorter timeframe and go to (1).

Note that the file name tried with timeframe can be configured using the
configuration variable DB::text::file_extension and
DB::genericdbi::prices_sql::<timeframe>.

However, this scheme works only for data in Text files and genericdbi.
All other data access mechanisms "die" if data is not loaded correctly
for the default market.

Note that this scheme is not really the best. Any data access that does
not support this scheme (e.g., bean, HTTP, pg, Metastock, CSV)
needlessly has a loop built in trying to load non-existent files until
it hits the die statement.

These scheme also prevents a sensible error message, as we do not know
whether the problem is from accessing data not there because of the
timeframe or because it is not there, period.

I think that lookup for additional data files or data sources should be
pushed into the data base module, so that we can avoid aborts or give
better error messages.

Th.

> -----Original Message-----
> From: Robert A. Schmied [mailto:ras
AT
acm.org]
> Sent: Monday, May 05, 2008 12:27 PM
> To: devel
AT
geniustrader.org
> Subject: Re: [GT] Trouble with backtest.pl and beancounter
> 
> Nicholas Kuechler wrote:
> > Thanks for the reply.
> >
> > Regarding: "The beancounter DB module does not support intraday
> data."
> > I did some checking to figure out what the problem with my data, so
I
> added
> > the $code to the message, so I could see what data was in my
database
> for
> > that code.
> 
> nick, thomas and all other interested gt'ers
> 
> i never really understood why that die message was so poorly
configured
> and have removed it from the bean.pg i use (and have added
considerably
> more). in any case, the general recommendation (and i'm not sure that
i
> agree with it, is that all sql based database (maybe that should be
sql
> databases that support the dbi api) users should adopt the
> genericdbi.pm
> module.
>