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?
Thanks,
David
Daniel John Debrunner wrote:
[EMAIL PROTECTED] 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_FETCH_DIRECTION = "XJ064.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.
