Oh, the usual. Stick your head in the ground or run away when anything happens. Maybe it doesn't translate well? Darn this English as a first language!
On Thursday 23 March 2006 07:02 pm, David W. Van Couvering wrote: > I do have to ask, what does it mean to emulate an ostrich? > > David > > Ryan P Bobko wrote: > > Thanks for the advice. That's probably what I needed to hear. > > > > ry > > > > On Thursday 23 March 2006 06:31 pm, David W. Van Couvering wrote: > >>Yes, I see what you're saying, you're rewriting JDBC extended with file > >>transfer. > >> > >>You could take the Derby source and extend it so that you can do file > >>transfer functionality, but then you're stuck with your own fork of > >>JDBC. And I'm sorry to say that the Derby community would likely not > >>accept your changes back (someone correct me if I'm wrong) because there > >>would be non-standard extensions to JDBC, and we strive to be > >>standards-compliant as a community. > >> > >>Personally, I would just open two connections: one for JDBC work and one > >>for file transfer. Keep them separate. > >> > >>David > >> > >>Ryan P Bobko wrote: > >>>Thanks for the advice, but I'm not sure if that will help. I now realize > >>>what makes me uneasy about my architecture is that I feel like I'm > >>>rewriting JDBC little by little just so I can have my file-moving piece > >>>on top of it. JDBC works great for my purposes, so my preference would > >>> be to remove my custom protocol whenever possible. Is it feasible to > >>> extend the JDBC API? Or will that just be more trouble than it's worth? > >>> > >>>I realize I just changed my question. Any more advice? > >>> > >>>ry > >>> > >>>On Wednesday 22 March 2006 07:23 pm, David W. Van Couvering wrote: > >>>>A common way client applications working with large result sets have > >>>>handled the "too much memory" problem that I've seen is to send the > >>>>results over in chunks. Instead of sending all 120,000 records in one > >>>>response, just send 100 or 1,000. The client processes those 1,000 > >>>>records, throws them away, and get the next 1,000. > >>>> > >>>>Would that work for you? > >>>> > >>>>David > >>>> > >>>>Ryan P Bobko wrote: > >>>>>Hi List, > >>>>>First of all, I can't say enough how impressed I've been with Derby. > >>>>>Every time I've thought this embedded wouldn't be able to do something > >>>>> I expect from a "full-blown" database (nested selects, correlated > >>>>> subqueries, stored procedures, you name it), it's suprised me. I love > >>>>> it. > >>>>> > >>>>>This isn't strictly a Derby question, but I'm hoping for some advice > >>>>> or suggestions with how to procede. I've been working on an > >>>>> application that is a sort of half-database, half-FTP client/server > >>>>> setup. The protocol I've implemented between the client and server > >>>>> lets the app do things like run queries, but also move files around > >>>>> based on those results. Or insert rows into the database based on > >>>>> where files have moved to. Files can be moved from the server to > >>>>> client and vice versa. > >>>>> > >>>>>Things have been working just fine, except that when I run queries, > >>>>> the server process does all the work and returns the results as a > >>>>> vector of string arrays. It's never sat well with me--and as you can > >>>>> imagine--now that the dataset is getting pretty big (120.000-4KB rows > >>>>> returned for some queries), I'm using too much memory. > >>>>> > >>>>>What I'd like to do is get my jdbc connection object onto the client > >>>>> so I don't have to "package" everything up when returning resultsets. > >>>>> The question is how? My first idea was to just use derby's network > >>>>> server and write the file protocol separately, but I'd prefer to > >>>>> stick with just one socket if I can. > >>>>> > >>>>>Advice? Thanks for your time. > >>>>>ry -- When I turn into one of them, I will no longer be Jacob. I will be a lapdog of Satan.
