db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Date Fri, 24 Jun 2005 18:29:38 GMT
Hi, Dan.  Can you clarify me the motivation behind keeping the footprint 
down?  Are we targeting PDAs?  What kind of platforms are you 
envisioning for Derby that require a minimal footprint?  I agree that in 
general smaller is better, but for instance is smaller a priority over 
readability/maintainability (for example, building an architecture with 
fewer classes doing more things rather than more classes with 
well-defined responsibilities)?  Is it a priority over performance?  Is 
it a priority over more advanced features such as replication, XML 
support, additional SQL features, etc.?  What's the order of precedence 
for these types of key qualities of Derby, in your view?



Daniel John Debrunner wrote:

> Oyvind.Bakksjo@Sun.COM wrote:
>>Daniel John Debrunner wrote:
>>>rather than a new error XJ074.S, the existing generic error XJ081.S
>>>(added by Shreyas) could have been used.
>>OK. Considering e.g. these existing codes (see below), it was not clear
>>to me what was the preferred way - adding a separate code or using a
>>generic one.
>>    String INVALID_FETCH_SIZE = "XJ062.S";
>>    String INVALID_MAX_ROWS_VALUE = "XJ063.S";
>>    String INVALID_ST_FETCH_SIZE = "XJ065.S";
>>    String INVALID_MAXFIELD_SIZE = "XJ066.S";
> I think the discussion was that when Shreyas added a new similar message
> and ita was resolved that adding a generic message and that existing
> code could converge to its use over time.
> I can add a Jira entry for this. My "itch" is keeping the footprint down
> in whatever way possible.
> Dan.

View raw message