mybatis generator: can we use ${alias} parameters

382 views
Skip to first unread message

Ilko

unread,
Mar 1, 2016, 12:28:04 PM3/1/16
to mybatis-user
Hi,

is it possible to configure the generator to generate the alias as parameter as in the mybatis example:

<sql id="Base_Column_List">
    <!--
      WARNING - @mbggenerated
      This element is automatically generated by MyBatis Generator, do not modify.
      This element was generated on Tue Jan 26 16:25:45 CET 2016.
    -->

    ${alias}.COL1, ${alias}.COL2, ...

 </sql>

As far as I can see mybatis does not treat the ${alias} as optional at the moment and all the generated sql statements must provide valid alias in the include element, so either this should be done in the generator as well or mybatis could be extended to treat the parameter as optional - if not provided the COL1, COL2 should be used without prefix.
This will ensure single point of change if the underlying tables are changed automatically - the Base_Column_List definition can be used very flexible in all queries.
I saw the alias attribute in the table element but this works statically at the moment.

Any ideas how this can be accomplished?

TIA,
Ilko

nclemeur

unread,
Mar 16, 2016, 10:00:31 AM3/16/16
to mybatis-user

Yes, I agree that going this path would be potentially very useful. You could imagining using different aliases when joining the same table twice and still be able to reuse the Base Column List. Also, you could think of extending the generated Example classes to have an alias as a constructor argument. We would then only need an api selectByExample that could take a "smart" example class that now how to combine multiple example together based on aliases. I know this is not really clear, but I think if we could create SQL query with JOINS and other more complex statement using the generated columns lists and examples would be a real plus for the generator...

Nicolas

Ilko

unread,
Apr 1, 2016, 7:59:04 AM4/1/16
to mybatis-user
sorry for the late reply - yes, I'm struggling already with this limitation - any ideas how can we proceed here - I can imagine I can invest some time to contribute here. At the very beginning I think it should be clarified if this could / should be done as plugin in the generator or it is not possible and should be in the generator itself?
Some guidance in any case will be very helpful.

Iwao AVE!

unread,
Apr 1, 2016, 12:49:04 PM4/1/16
to mybatis-user
Hi guys,

Just an idea, but how about 1) omitting 'alias' attribute of 'table'
element in the generator config file and 2) adding ${alias} to
Base_Column_List using a custom plugin?

${alias}col1, ${alias}col2, ...

All the generated statements, example classes reference columns
without alias and will work fine.

Here's an example implementation of the plugin.
https://gist.github.com/harawata/d29e49f2c75c5500ae0acf19b6a7d090

Regards,
Iwao

Ilko

unread,
Apr 2, 2016, 4:24:16 PM4/2/16
to mybatis-user
I'll give it a try on Monday. However, if the memory serves me well I think that the generated selectById statements are referencing the Base_Column_List. Nevertheless, I can use the idea as a starting point - I think we could create a copy of the whole element as an Aliased_Base_Column_List...
Thanks for sharing the idea.

Iwao AVE!

unread,
Apr 2, 2016, 7:29:19 PM4/2/16
to mybatis-user
Hi Ilko,

Yes, some generated select statements reference Base_Column_List, but
it shouldn't be a problem because ${alias} will be an empty string if
there is no property defined.

So, for example, with a Base_Column_List like this

<sql id="Base_Column_List">
${alias}col1, ${alias}col2
</sql>

, generated select such as...

select
<include refid="Base_Column_List" />
from ...

will execute...

select col1, col2 from ...

In reality, though, Base_Column_List may need column aliases as well.

<sql id="Base_Column_List">
${alias}col1 as ${prefix}col1, ${alias}col2 as ${prefix}co2
</sql>

Let us know how it goes :-)

Cheers,
Iwao


2016-04-03 5:24 GMT+09:00 Ilko <ilkom...@gmail.com>:
> I'll give it a try on Monday. However, if the memory serves me well I think that the generated selectById statements are referencing the Base_Column_List. Nevertheless, I can use the idea as a starting point - I think we could create a copy of the whole element as an Aliased_Base_Column_List...
> Thanks for sharing the idea.
>
> --
> You received this message because you are subscribed to the Google Groups "mybatis-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mybatis-user...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Ilko

unread,
Apr 5, 2016, 8:25:59 AM4/5/16
to mybatis-user
Hi,

I've posted my version as reply to your gist - I've ended with second element as copy of the Base_Column_List. I think that it is better suited to be added to the BaseColumnListGenerator, which I've used in the plugin...

as I wrote improvements are highly appreciated because it is my first plugin ...

Nicola Menegazzo

unread,
Oct 1, 2019, 4:09:42 AM10/1/19
to mybatis-user
Hi guys, sorry for posting on a such old thread but I wasn't able to find a solution elsewhere...

Do new versions of myBatis allow managing prefixes in a native and optimal way? I got some myBatis Generator "column_list"s that I need to prefix because of joined tables field ambiguity.
I think it should be quite straightforward to add a parameter to an include statement to automatically prefix all listed columns.

A possibile example:

  <sql id="Base_Column_List">
    id, code, name, address1, address2,
    city_id, city_name, country_code, postal_code, latitude, longitude
  </sql>

then

<include item_prefix="columnPrefix." refid="Base_Column_List" />

would generate

columnPrefix.id,
columnPrefix.code,
columnPrefix.name,
columnPrefix.address1,
columnPrefix.address2,
columnPrefix.city_id,
columnPrefix.city_name,
columnPrefix.country_code,
columnPrefix.postal_code,
columnPrefix.latitude,
columnPrefix.longitude

above all, without the need to modify the original <sql id="Base_Column_List">.


Hope someone is listening on the other side :)
Thanks anyway

Regards
Reply all
Reply to author
Forward
0 new messages