On Tue, 2008-03-18 at 09:11 -0500, Jeff Butler wrote:
> now. As far as multiple databases, I know Brandon has made this work
> by passing the query string as an unresolved property to the
> <generatedKey> element - which will cause Abator to leave the property
> in the generated <selectKey> element - so you can pass the db specific
> query string at runtime. Use Abator from SVN for that support.
Cool thanks just what I need!
> 3. There are no plans to use freemarker or velocity for code
> generation in Abator. If I recall correctly, someone posted a
> freemarker implementation on the list quite a while ago.
Ok, thanks, was just wondering. The current implementation should be
fine for my needs.
> 4. There are many threads on the user list discussing Abator and table
> relationships. Your strategy is fine, but I would also suggest
> looking at the iBATIS support for the "groupBy" function -
> this *might* yield better performance in some circumstances.
I have looked at those, but was hoping to find a simple abator based
approach. But I'm happy enough for now, thanks.
> Jeff Butler
>
>
>
> On Tue, Mar 18, 2008 at 4:40 AM, Zach Visagie <[EMAIL PROTECTED]>
> wrote:
> Hi all
>
> I'm relatively new to ibatis, so sorry for the long mail.
> We've got
> basic web admin applications (using spring) for a
> transactional type
> product, which needs to support multiple database vendors.
> Some of the
> tables are quite denormalized so that's why I like ibatis over
> ORM stuff
> and my superiors don't like background magic and prefer
> simplicity above
> all and they like sql above ORM. I've also been tasked to
> improve
> development speed, so we are using abator.
>
> A couple of questions:
> 1. Abator auto generated keys.
> Is it possible for abator to use the auto_generated keys
> feature,
> instead of using a query? We have a custom connection pool
> able to
> return them even for postgres.
>
> 2. What strategies do you recommend for supporting multiple db
> vendors?
> The basic abator stuff should work on most db's or am I
> mistaken? This
> is also the reason for question 1, since I was hoping to
> generate the
> abator stuff from a single db and use it for the others and
> don't want
> the DAO's to have db specific stuff if I can avoid it.
>
> I thought to maybe add additional sqlmaps for any advanced
> requirements
> beyond abator dao's. And could have db specific queries for
> report-like
> situations in different sqlMaps loaded on startup based on db.
>
> 3. What is the estimated work for modifying abator to use
> velocity or
> freemarker templates for modifying code generation?
>
> 4. I want to expose relationships in domain classes to the UI
> but abator
> is unable to provide that. I figure that it will still save me
> on time
> to use abator and just manage the relationships in the service
> layer and
> in abstract super classes for the domain objects.
> UI <-> Service <-> DAO
>
> User
> name:String
> roles:List
>
> (AbatorGenerated)
> AdminUser extends User
> name:String
>
> public void createUser( User user )
> {
> userTableDAO.insert( user );
> List<Role> roles = user.getRoles();
> for( Role role : roles )
> {
> AdminUserRoleLnk lnk = new AdminUserRoleLnk( );
> lnk.setAdminUserId( user.getId( ) );
> lnk.setAdminRoleId( role.getId( ) );
> adminUserRoleLnkDAO.insert( lnk );
> }
> }
>
> The problem comes in an extra iteration needed for retrieving
> the user's
> roles, as the following example shows.
>
> public List<User> findUsers( )
> {
> AdminUserExample example = new AdminUserExample( );
> example.setOrderByClause( "username" );
> List<User> users = adminUserDAO.selectByExample( example );
> for( User u : users )
> {
> List<Role> roles = getUserRoles( u.getId() );
> u.setRoles( roles );
> }
> return users;
> }
>
> I can live with it for smaller tables, since performance is
> not a major
> requirement, but any other suggestions? Is there any way to
> pass a row
> handler down to the DAO? I don't see a way to pass a row
> handler to the
> spring dao classes, or am I just missing it or is there some
> other way
> to process each row? Of course this I'd like in the context of
> minimal
> interference with generated code and minimal work effort,
> which is a
> high priority due to many tables.
>
> Regards
> Zach
>
>
>
>
>
>
>
>
>
>
