Nope. Looks good, Apache licence too so it's usable. Why am I not surprised that Strachan is on it :) He gets everywhere. My rule of thumb is becoming: "it's not an open source Java project if Strachan's not on it. " [Damn, hurry up and join DbUtils James].
I'll try to learn more about it so that DbUtils doesn't grow in that direction, which a couple of Mike's suggestions concering the ColumnData might be getting towards (?). Assuming you're the Travis who's heading up crossdb.com, what do you think? Is DbUtils redundant? Can you see a clear separation of concern? Are there any things you think would go well there. The reason why I think there's not a cross-pupose: I'm not an amazing Db coder or anything, I do bits etc. When I look around at all the libraries to help me with DBs, they all involve me having to get religious about them, OO-db's, ObjectBridge, Castor/JDO, CrossDB[I think]. I like getting religious about things, but it's expensive to do properly [in time], so when I haven't got that time I like to just make the boring old religion that little bit easier. One of the issues I believe DbUtils has to watch for is introducing any religion. So, if someone _has_ to use a framework to get the power, then we're starting to compete with the other projects and not fitting the currently empty niche. Idea is just to make JDBC(tm) easier. Currently I'm wrestling with a DbPoller. It's a simple piece of code which polls the db to notify something when that table changes. Issues being: 1) I introduce a PKey class to hold a column-data info. Basically akin to Mike's suggestion. Is this a framework yet? 2) DB-specific. Oracle has some irritating bugs with jdbc and I extend DbPoller to get OracleDbPoller. This provides some issues for building, but I'm sure they can easily be fixed. More importantly, should DbUtils fill up with lots of DB-specific extensions [or in a side repository anyway]. Another idea is GUID/Sequencers. Would be nice to have a Sequencer interface and then I make an OracleSequencer which uses a select on nextval etc, or a MySql sequencer with last_insert_id. Issues being, how do I enforce the last transaction there? There'd also be java-level random-number Sequencers, which would use the sequence-id code from Patterns sandbox, or other ideas. Is this getting towards a framework? Thoughts? Hen On Thu, 14 Nov 2002 [EMAIL PROTECTED] wrote: > Anybody looked at www.crossdb.com ? > > Travis > > ---- Original Message ---- > From: Mike Bryant <[EMAIL PROTECTED]> > Sent: 2002-11-14 > To: [EMAIL PROTECTED] > Subject: [DBUtils] Introduction and some thoughts > > Hello all, > > My name is Mike Bryant. I just wanted to send an email to introduce > myself and say that I am excited about the DBUtils package. I've spent a > good bit of time at my current job writing database utility code, a > package like this could have really saved some time. > > The code so far looks great I think. I am especially impressed with the > EnhancedResultSet class and the DbUtils.resultSetToArray method. > > Some thoughts I have on this package: > - Data class (ColumnData) to hold a DB field's data. This might contain > data like column index, data type, column name, value. > - Method (similar to DbUtils.resultSetToArray method) that would build a > List (or maybe Map) of ColumnData objects. This might be useful if users > need more information than the resultSetToArray method provides. > - Method to take a SQL stmt as a param, execute it, build a List of > ColumnData objects (or a List of Strings), representing a vertical list of > column data. An example of this would be to use a stmt like 'select > user_name from users' to get a List of all users. > > Anyway, those are some general thoughts. I look forward to (hopefully) > spending alot of time with this. > > Thanks > > Mike Bryant ([EMAIL PROTECTED]) > > > > > -- > To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org> > > > > -- > To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org> > > -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
