|
Re: Teneo: Max length forced even when annotation set [message #1117391 is a reply to message #1117282] |
Thu, 26 September 2013 11:41 |
Martin Taal Messages: 5468 Registered: July 2009 |
Senior Member |
|
|
Hi Rob,
There is also this option: teneo.naming.auto_adapt_manual_set_sql_names
(see the PersistenceOptions class), its default value is true.
Can you try with this option to false?
gr. Martin
On 09/26/2013 11:19 AM, Rob Mising name wrote:
> Hi Martin,
>
> I have a problem that I would really like your opinion on. When we use DB2 as the database we are seeing some
> undesirable behaviour.
>
> With DB2 there are limits as follows:
>
> Table Name Size: 128
> Column Name size: 30
>
> So in order to ensure that columns like those used in join and index (_IDX) columns get a suitable sized name I have to
> set the column name to (optionMaximumSqlLength) to 30 [Unfortunately it does not appear there are different ones for
> Table and columns name - so I just have to set one to the lowest value]
>
> I then construct my eCore with an annotation to set the name (using our own naming pattern) for the Table, which on DB2
> will be restricted to 128 characters.
>
> @JoinTable(name="MY_LONG_NAME_ORDERMODEL_EMPLOYEE_ORDERSTAKEN")
>
> So this takes more than 30 characters - but as I have specified an annotation it will not do a callback on the
> TeneoSQLNameStrategy class for the name to be set. (As I would have expected).
>
> However, it does then truncate the size of the entry to be within the optionMaximumSqlLength that we had to set earlier.
> I debugged into the code a bit and it appears to be within "EntityMapper.createEntity()":
>
> if (table.getName() != null) {
> target.addAttribute("table", getHbmContext().trunc(table.getName(), false));
> log.debug("Table " + table.getName());
> }
>
>
> However, as I have set it by the annotation I wouldn't have expected it to be altered after that point (As we require
> the table to have the name given in the annotation).
>
> I would really like your help and opionion on how you think I may be able to work around this?
>
> Thank you
>
> Rob
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@xxxxxxxx - mtaal@xxxxxxxx
Web: www.springsite.com - www.elver.org
|
|
|
|
Re: Teneo: Max length forced even when annotation set [message #1117565 is a reply to message #1117282] |
Thu, 26 September 2013 15:21 |
Rob Mising name Messages: 118 Registered: July 2010 |
Senior Member |
|
|
Hi Martin,
I have been looking at a possible work around for this, and thought that I would post what I was planning here just to make sure it isn't flawed. (Or missing something)
The change takes two parts, the first is in our custom "TeneoSQLNameStrategy", override the method "trunc" and have it just return the value that is passed in (So no processing of the string is done).
The result of this is that we must always specify names for tables, columns, index's etc in the eCore annotations (Which we do already as it happens) and make sure they do now exceed the supported length for the given DB.
This leaves the problem that there is no way to set the _IDX column in the eCore, so I have had to extend the behaviour of TeneoSQLNameStrategy to support being called to name the _IDX column.
Then change the method: getIndexColumnName(PAnnotatedEStructuralFeature aFeature) in the class "AbstractAssociationMapper" to instead of it's existing behaviour, make a call to the custom TeneoSQLNameStrategy in order to retrieve the name for the _IDX column. In this case, the method can just call the original trunc method i.e. super.trunc() in order to persist the correct behaviour to stop the column name length being exceeded.
Does this all sound OK?
Thanks, Rob
|
|
|
Re: Teneo: Max length forced even when annotation set [message #1120167 is a reply to message #1117565] |
Sun, 29 September 2013 08:44 |
Martin Taal Messages: 5468 Registered: July 2009 |
Senior Member |
|
|
Hi Rob,
Yes this sounds okay, but to me the first issue (auto_adapt_manual_set_sql_names not working for jointable names, seems
to be a bug. I will solve this. Can you enter a bugzilla for this?
The second topic I can also solve through an annotation but it is slightly more work as I need to introduce an
annotation for this. But feel free to enter a bugzilla for this as well.
gr. Martin
On 09/26/2013 05:21 PM, Rob Mising name wrote:
> Hi Martin,
>
> I have been looking at a possible work around for this, and thought that I would post what I was planning here just to
> make sure it isn't flawed. (Or missing something)
>
> The change takes two parts, the first is in our custom "TeneoSQLNameStrategy", override the method "trunc" and have it
> just return the value that is passed in (So no processing of the string is done).
>
> The result of this is that we must always specify names for tables, columns, index's etc in the eCore annotations (Which
> we do already as it happens) and make sure they do now exceed the supported length for the given DB.
>
> This leaves the problem that there is no way to set the _IDX column in the eCore, so I have had to extend the behaviour
> of TeneoSQLNameStrategy to support being called to name the _IDX column.
>
> Then change the method: getIndexColumnName(PAnnotatedEStructuralFeature aFeature) in the class
> "AbstractAssociationMapper" to instead of it's existing behaviour, make a call to the custom TeneoSQLNameStrategy in
> order to retrieve the name for the _IDX column. In this case, the method can just call the original trunc method i.e.
> super.trunc() in order to persist the correct behaviour to stop the column name length being exceeded.
>
> Does this all sound OK?
>
> Thanks, Rob
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@xxxxxxxx - mtaal@xxxxxxxx
Web: www.springsite.com - www.elver.org
|
|
|
|
Powered by
FUDForum. Page generated in 0.03645 seconds