|
Hi Guys, whats the best
way to insert a row with ibatis when your key column
is generated from a sequence on the DB ? Would I edit the sql
in the sql map ? or is there a clever way to do it? -----Original
Message----- If you want to hear a
guaranteed lie, then ask an open source committer the "when"
question. :-) Seriously, I can probably
get it finished over the weekend. I have to work for a living until then. Jeff Butler On GOOD MAN JEFF ! I can downcast before I
call insert easy enough. When do you figure this
will be available ? (got a project going live early May) Cheers Paul. -----Original
Message----- I've been without power for a couple of days due to a
bad storm, so I've missed some of the debate too. I'm going to sidestep
the whole "OOP best practices" talk (sound and fury). As for Abator, I can make the change to allow you to
specify a base class for the domain objects, and a base interface for the DAO
interface. I really don't care for the downcasting thing - could you live
without it (do the downcast somewhere else)? BTW - downcasting is a sign
of a non-polymorphic system, so I don't think that's exactly what you
mean: polymorphism implies no casting. You could also write your own DAO generator that did
the downcast. Jeff Butler
On Well I'm glad I caused
quite a discussion on OO vs Maps , but I guess you guys are all in the states,
so I've got a day's delay before I get any responses J . I read all your
mails about maps and arraylists etc, and I don't think it really applies to my
problem. I have a bunch of XMLObjects hydrated from an MDB's message. I need to
get these into the DB, but at the same time keep the design loosely coupled so
that I can plug in a different kind of output writer ( e.g. to another MQ
queue, to a flat file, to CICS transaction gateway etc etc). So I have a Writer
interface, one implementation of which is an SQLWriter, which uses the iBatis
framework to insert each XMLObject to the DB. I'm starting with XMLObjects that
are actually value objects, so it makes sense to use DAO's. Now then ….abator
generates the DAO's perfectly well for me, but the OO is wrong, as all the DAO
interfaces that are generated are at the top level of their own
hierarchy……there is no commonality between DAO's i.e . here is a cut down
example of an abator generated DAO. public interface
ManufactureRequestDAO { void
insert(ManufactureRequest record); } The generated dao
interfaces should extend a common BaseDAO interface ( as after all , they are
all DAO's !) and have methods that accept a BaseVO…… public interface
ManufactureRequestDAO extends BaseDAO { /** *
This method was generated by Abator for iBATIS. *
This method corresponds to the database table upca.manufacture_request
* *
@abatorgenerated Wed Mar 01
*/ void insert(BaseVO record); void
insert(ManufactureRequest record); } When abator generates the
Implementation DAO's it should add a method to downcast the passed BaseVO to
the relevant type and call the genuine insert method:- public class
ManufactureRequestDAOImpl extends SqlMapDaoTemplate implements
ManufactureRequestDAO { public
ManufactureRequestDAOImpl(DaoManager daoManager ) {
super(daoManager); }
public void insert(BaseVO vo) throws ClassCastException {
insert((ManufactureRequest) vo);
} public
void insert(ManufactureRequest record) {
insert("upca_manufacture_request.abatorgenerated_insert", record); } } Making these small
changes to abator would not change ANY of the existing behaviour, everyone
would still be able to use it exactly as they were doing, and more importantly
the framework will continue to behave exactly as it was doing, but it would add
so much more flexibility. PLEASE DO IT ….PWEDDY PWEESE. As for the ArrayList /
Maps/ OO debate…. I've never used anything other than DAO's VO's, SO If anyone
can gimme a clue where to start with the Maps method that'd be handy……BEAR IN
MIND that I have to start with a collection of XMLObjects, which are actually
already value objects. Best Regards Paul Carr . -----Original Message----- Sent:
On Oddly enough it's this
flexibility that has made iBATIS indispensible to us. The abstraction of
"the data and behaviors are java domain objects in memory" just
doesn't work for us for a host of reasons. Our tables are big and normalized,
we do mainly set-based operations, work with dynamically defined relations
(actual new tables, not views), rely on covered indexes for performance, use
materialized views in many cases, and these aspects preclude using fully
hydrated domain objects, JavaBean-based or otherwise. Sometimes its better not
to ask whether maps are better than domain objects (which they clearly aren't),
but rather whether domain objects are the right choice at all for your
application. Sets and Lists of Maps "map" to a generic relational
model quite well and sometimes offer a much better solution (no pun
intended there) ;-) Using iBATIS to cleanly structure the SQL has been
fantastic, much better than the usual JDBC + SQL string construction garbage we
all see from time to time. Steve From: Clinton
Begin [mailto:[EMAIL PROTECTED]]
Fair enough, I agree. You're argument is valid
against Sun's design for JavaBeans and the pattern matching approach of
getters/setters -- and how they are hardly a best OOP practice (I won't get
into that OOP itself isn't necessarily a best practice).... On Actually, I've long been annoyed with all our
frameworks forcing me to expose all my |
- Using sequences Paul Carr
- Re: Using sequences Diran Ayandele
- RE: Using sequences Bruyn Bill
- Re: Using sequences Diran Ayandele
- RE: Using sequences Paul Carr
- Re: Using sequences Jeff Butler
- RE: Using sequences Paul Carr
- Re: Using sequences Larry Meadors
- RE: Using sequences Paul Carr
- RE: Using sequences Paul Carr
- Re: Using sequences Diran Ayandele
