[BioSQL-l] BioSQL bug in bugzilla

[Erik Rijkers]

Hi Hilmar,

Sorry, it's too long ago.  I can run it again (with new
versions) somewhere next week.  I don't remember which of
the two problems (parser or data size) it was in my case.

If it is true what you say (that most errors are due to
the parser), it might indeed be better to leave those
constraints in until such time that the parser has become
more trustworthy, and use the database as a test
instrument...

What is really needed of course is a place to run these
loading scrips continually against any appearing new
versions of parsable text, and against the different
database backends.

Does that already happen somewhere?

Should we consider such a bioperl buildfarm / loadfarm?

(I might be able to help with any postgres loading tests.)

Thanks,

Erik Rijkers

On Sun, March 2, 2008 18:39, Hilmar Lapp wrote:
> I don't think it's a good idea to just replace all
> varchar() types
> with type text.
>
> First of all, having reasonable constraints is a Good
> Thing(tm) in my
> book as the majority of times I found them violated it
> revealed a
> parsing error, rather than the constraints not fitting the
> data.
> Second, this won't solve the problem for the other RDBMS
> versions for
> which there is a real performance penalty and other
> implications when
> having unreasonably large column widths.
>
> That said, if the constraint is indeed not compatible with
> current
> data (such as Uniprot) we have a problem that needs to be
> fixed. So,
> what I would like to find out is
>
> 1) is this in reality a parsing error, or is there indeed
> a value for
> a column that in BioSQL is constrained to 40 chars, and
>
> 2) if so, which column in which table is the problem.
>
> Erik - would you mind sending me the full error stack if
> you still
> have it? Usually load_seqdatabase.pl will also print an
> extra warning
> message saying what it couldn't store. That message would
> be great
> too. If you don't have either anymore, do you remember
> vaguely what
> those messsages said? Alternatively, do you have the
> offending
> uniprot entry (or its accession)?
>
> I suspect that it's actually the constraint on
> dbxref.accession. Does
> that ring a bell?
>
> 	-hilmar
>
>
> On Mar 1, 2008, at 3:42 PM, Chris Fields wrote:
>
>> Hilmar,
>>
>> Just wanted to point out a bug which I thought was
>> bioperl-db-
>> related but is really BioSQL.  Could you take a look to
>> see what
>> you think?
>>
>> http://bugzilla.open-bio.org/show_bug.cgi?id=2389
>>
>> chris
>> _______________________________________________
>> BioSQL-l mailing list
>> BioSQL-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/biosql-l
>
> --
> ===========================================================
> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net
> :
> ===========================================================
>
>
>
> _______________________________________________
> BioSQL-l mailing list
> BioSQL-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biosql-l
>