[DAS2] RE: Problem with parent/child features in biopackages server feature response

[Helt,Gregg]

Thanks, whatever you did fixed the problem!

	gregg

> -----Original Message-----
> From: Allen Day [mailto:allenday at ucla.edu]
> Sent: Monday, October 17, 2005 11:15 PM
> To: Helt,Gregg
> Cc: das2 at portal.open-bio.org
> Subject: RE: Problem with parent/child features in biopackages server
> feature response
> 
> Okay, give it a shot now.  You uncovered a bug in my SQL query where
the
> parent feature was outside your overlaps+inside ranges and wasn't
being
> retrieved, leading to an error.  These two are now in my regression
test
> suite.
> 
> -Allen
> 
> 
> On Mon, 17 Oct 2005, Helt,Gregg wrote:
> 
> > Thanks for the quick fix!
> >
> > Now I'm seeing another problem though.  Some feature queries with a
> > combination of one "overlaps" and one "inside" filter are giving
weird
> > errors.  But some return correctly.
> >
> > For example,
> >
http://das.biopackages.net/das/genome/human/17/feature?overlaps=chr21/26
> > 104961:26271647;inside=chr21/26104961:46976097;type=SO:mRNA
> > returns correctly.
> >
> > But
> >
http://das.biopackages.net/das/genome/human/17/feature?overlaps=chr21/25
> > 854314:26027736;inside=chr21/0:26027736;type=SO:mRNA
> > does not, instead returning these headers:
> > 	HTTP/1.1 200 OK
> > 	Date: Mon, 17 Oct 2005 22:40:54 GMT
> > 	Server: Apache/2.0.51 (Fedora)
> > 	X-DAS-Version: DAS/2.0
> > 	X-DAS-Server: GMOD/0.0
> > 	X-DAS-Content-Type: text/x-das-feature+xml
> > 	X-DAS-Status-Details: Died at
> > /usr/lib/perl5/site_perl/5.8.3/Package/Base/Devel.pm line 425.
> >
> > and then what appears to be more headers but is designated as
content
> > (so I'm guessing a header-terminating blank line got inserted before
> > these):
> > 	X-DAS-Status: 500
> > 	X-DAS-Status: 200
> > 	Content-Length: 0
> > 	Keep-Alive: timeout=15, max=100
> > 	Connection: Keep-Alive
> > 	Content-Type: text/xml
> >
> > The combination of an "overlaps" and "inside" filter is an important
> > part of IGB's client-side query optimizations.  I can turn this
> > optimization off for now, but I'm hoping you can diagnose and fix
the
> > problem.
> >
> > 	Thanks again,
> > 	Gregg
> >
> > > -----Original Message-----
> > > From: Allen Day [mailto:allenday at ucla.edu]
> > > Sent: Monday, October 17, 2005 2:50 PM
> > > To: Helt,Gregg
> > > Cc: das2 at portal.open-bio.org
> > > Subject: Re: Problem with parent/child features in biopackages
server
> > > feature response
> > >
> > > Hi Gregg,
> > >
> > > There was a logic inversion in my code.  PARENT/PART relationships
> > should
> > > now be restored.
> > >
> > > Andrew, I'd also like to know if there is some code already
written
> > that
> > > can be written into my regression tests.
> > >
> > > I understand that it's really irritating to have non-fatal errors
of
> > > different types continuously appearing.  Maybe I should spend some
> > time
> > > beefing up the regression test suite to do things like diff
feature
> > graphs
> > > and make sure they are identical?  Something to discuss on the
> > conference
> > > call...
> > >
> > > -Allen
> > >
> > > On Mon, 17 Oct 2005, Helt,Gregg wrote:
> > >
> > > > I finally got back to testing DAS/2 feature requests/responses
in my
> > IGB
> > > > client.  I'm seeing a new problem in responses from the
biopackages
> > > > server, there are no <CHILD> or <PARENT> elements for features
at
> > all.
> > > >
> > > > See for example the returned XML from my standard test query:
> > > >
> >
http://das.biopackages.net/das/genome/human/17/feature?overlaps=chr21/26
> > > > 027736:26068042;type=SO:mRNA
> > > >
> > > > ...
> > > > <FEATURE id="feature/BC001178" type="type/SO:mRNA"
name="BC001178">
> > > > 	<LOC pos="region/chr21/26018728:26029854:-1"/>
> > > > 	...
> > > > </FEATURE>
> > > > <FEATURE id="feature/auto316726" type="type/SO:three_prime_UTR"
> > > > name="auto316726">
> > > > 	<LOC pos="region/chr21/26018728:26018820:-1"/>
> > > > </FEATURE>
> > > > ...
> > > >
> > > > But I know that "auto316726" should be a child of "BC001178".
> > > >
> > > > Andrew, would your DAS/2 validator catch problems like this?
> > > >
> > > >
> > > > 	Thanks,
> > > > 	Gregg
> > > >
> > > >
> >