Re: [jbosstools-dev] Unpredictable NamingStrategy interpretation
by Andersen Max
We integrated naming strategy into Eclipse JPA tooling so when it checks if a table/column
exists it won't just use the JPA defaults.
And I assume Dimitry found some inconsistency in that work.
But yeah, i'm also not fully following what Dimitry's problem is beyond
why @Entity(name="e.M11") doesn't result in e_M11 as table name ?
/max
On May 12, 2010, at 18:12, Emmanuel Bernard wrote:
> You guys lost me, I'm out of context.
> Any change I get the actual naming strategy code, the Hibernate Annotations and Core version you are talking about and more important what are you guys trying to do :)
>
> On 12 mai 2010, at 18:02, Andersen Max wrote:
>
>>
>> On May 12, 2010, at 16:54, Dmitry Geraskov wrote:
>>
>>> Hi, Emmanuel,
>>>
>>> The problem is in interpretation of specified names with dots.
>>>
>>> I created naming strategy where all method just join all passed parameters with "_".
>>> For example
>>> @Override
>>> public String collectionTableName(String ownerEntity, String ownerEntityTable, String associatedEntity,
>>> String associatedEntityTable, String propertyName) {
>>> return ownerEntity + "_"+ associatedEntity+ "_" + associatedEntityTable + "_" + associatedEntity +
>>> "_" +propertyName;
>>> }
>>>
>>>
>>> And what I have found:
>>>
>>> @Entity(name = "e.M11")
>>> public class ManyToMany1 implements Serializable {
>>>
>>> }
>>>
>>
>> but that is not a collection table - its an Entity Table ...
>>
>>> What do you think will be DB table name? The correct answer is "e.M11".
>>
>> I would have assumed e_M11 ....so yeah thats a bit surprising.
>>
>>> The same for @Entity @Table(name = "e.M11")
>>>
>>
>> Here you are overriding namingstrategy so that shouldn't be surprising.
>>
>>> But when this entity is used in relationship mapping as target entity things become different:
>>> for @Entity(name = "e.M11") entity.ManyToMany2_entity.ManyToMany1_M11_entity.ManyToMany1_mtm1
>>> for @Table(name = "e.M11") entity.ManyToMany2_entity.ManyToMany1_e.M11_entity.ManyToMany1_mtm1
>>
>> I'm not seeing this as different. In one case you are saying naming strategy should do its thing Entity(name="e.M11")
>> and in the other you override it (i.e. @Table(name="e.M11").
>>
>> Remember name on entity is for *entity*-name not table name.
>>
>>> I didn't see any specification for how NamingStrategy should be used. And I even *fear* to compare this behaviour with core hibernate behaviour. I guess there will be some differences too.
>>
>> I remember emmanuel having fun with mapping JPA naming standards over to Hibernate NamingStrategy especially when
>> it came to collections and entity names ...but I don't recall the conclusion.
>>
>> Surprised entity name's doesn't seem to be processed on equal footing as class names. (i.e. why does @Entity(name="e.M11") not reasult in e_M11 as table name ?
>>
>> /max
>>
>
15 years, 12 months
Unpredictable NamingStrategy interpretation
by Dmitry Geraskov
Hi, Emmanuel,
The problem is in interpretation of specified names with dots.
I created naming strategy where all method just join all passed
parameters with "_".
For example
@Override
public String collectionTableName(String ownerEntity, String
ownerEntityTable, String associatedEntity,
String associatedEntityTable, String propertyName) {
return ownerEntity + "_"+ associatedEntity+ "_" +
associatedEntityTable + "_" + associatedEntity +
"_" +propertyName;
}
And what I have found:
@Entity(name = "e.M11")
public class ManyToMany1 implements Serializable {
}
What do you think will be DB table name? The correct answer is "e.M11".
The same for @Entity @Table(name = "e.M11")
But when this entity is used in relationship mapping as target entity
things become different:
for @Entity(name = "e.M11")
entity.ManyToMany2_entity.ManyToMany1_*M11*_entity.ManyToMany1_mtm1
for @Table(name = "e.M11")
entity.ManyToMany2_entity.ManyToMany1_*e.M11*_entity.ManyToMany1_mtm1
I didn't see any specification for how NamingStrategy should be used.
And I even *fear* to compare this behaviour with core hibernate
behaviour. I guess there will be some differences too.
Dmitry.
16 years
Re: [jbosstools-dev] Is there a way to tell the difference between a plug-in running in JBDS and one in JBT?
by Brian Fitzpatrick
I totally agree, but this seems to be an edge case (gotta love those).
The issue is that EGT requires one particular URL for .org and a different one for JBDS. For .org, the repository should show "/drools-guvnor/..." and for JBDS, it should be "/jboss-brms/...".
--Fitz
_______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, SOA-P
JBoss by Red Hat
----- Original Message -----
From: "Andersen Max" <max.andersen(a)redhat.com>
To: "Brian Fitzpatrick" <bfitzpat(a)redhat.com>
Cc: "tools-dev" <jbosstools-dev(a)lists.jboss.org>, "external-exadel-list" <external-exadel-list(a)redhat.com>
Sent: Wednesday, May 12, 2010 12:53:47 AM GMT -07:00 US/Canada Mountain
Subject: Re: [jbosstools-dev] Is there a way to tell the difference between a plug-in running in JBDS and one in JBT?
Platform.getBundle("pluginId") should help you but why would you want to do this ?
You shouldn't tie functionality to if a certain osgi plugin is loaded, but to weather a certain extension point or service is available.
i.e. Maven integration in jboss tools is separated out in to a separate plugin to ensure it only gets loaded when m2ecipse plugins
are around and avoids having a maven dependency to the other plugins (i.e. seam core can be used with maven but doesnt depend)
Another way (but should be kept to a minimum) is to use optional dependencies and do a load for the class you want inside a try/catch for
NoClassDefFoundError. Then your plugin still loads even if the optional plugin is not available and only fails if you try access these extra
classes which you can guard against with the try/catch.
The trick here is to ensure you don't references those optional dependencies except for a very few controlled places.
/max
On May 11, 2010, at 18:08, Brian Fitzpatrick wrote:
> Hi guys...
>
> We have a bug for the Eclipse Guvnor Tools (EGT) where we need to be able to tell whether we're running a particular plug-in in JBDS or JBoss Tools... Is there an easy check to determine this?
>
> --Fitz
>
> _______________________________
> Brian Fitzpatrick (aka "Fitz")
> Senior Software Engineer, SOA-P
> JBoss by Red Hat
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
16 years
Re: [jbosstools-dev] A tip: How to speed up SVN updates
by Andersen Max
(redirecting to the right list )
-max
On May 6, 2010, at 10:13, Andersen Max wrote:
>
> On May 5, 2010, at 10:26, Yahor Radtsevich wrote:
>
>> Hi Max,
>>
>> Regular svn updates (with short delta) are acceptable fast (5-10min under Windows), but in the cases when an old version is needed or to do svn switch, the updates are much longer:
>> svn update -r21899 (from r21862, 2 days old): 7m9s
>> svn update -r21862 (from r21485, 3 weeks old): 1h12m
>> svn update -r21888 (from r20458, 2.5 months old): 2h57m
>>
>
> How often do you do such operations ?
>
> Those times doesn't sound like something excluding documentation will fix, nor
> do they look extremely slow for a large codebase ?
>
>> Under Linux short updates take 1-2min, and there is no difference for long ones.
>
> So the problem is windows ?
>
> /max
>>
>>
>> On Tue, May 4, 2010 at 1:38 PM, Andersen Max <max.andersen(a)redhat.com> wrote:
>> Thanks for the tip...but How loong are those updates ?
>>
>> doing an svn update for me takes less than 1 minute, sometimes 1.5 minute.
>>
>> Rob (who is in China) just did it in 90 seconds from a coffee shop.
>>
>> What is the time for you ?
>>
>> /max
>>
>> On May 4, 2010, at 11:01, Yahor Radtsevich wrote:
>>
>>> Hi All,
>>>
>>> If you, like me, are annoyed by looooong time of trunk updates, there is a SVN feature to skip directories you do not use. This feature is called 'Sparse Directories'.
>>>
>>> For example, to delete directory 'documentation' from your local copy of trunk permanently, use the following command:
>>> svn update --set-depth empty documentation
>>> After this command, the documentation directory will be skipped during further updates and switches. (To restore it back, use --set-depth infinity).
>>>
>>> Windows users may use the following batch-script to delete all documentation and *\docs directories at once (just save as deletedocs.bat and run from trunk directory):
>>> @echo DELETING OF documentation...
>>> svn update --set-depth empty documentation
>>> @echo DELETING OF *\docs:
>>> @FOR /f %%d IN ('dir /b /a:d') DO (
>>> @IF EXIST %%d\docs\.svn (
>>> @echo DELETING OF %%d\docs...
>>> svn update --set-depth empty %%d\docs
>>> )
>>> )
>>>
>>>
>>> Best Regards,
>>> Yahor Radtsevich
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
>
>
16 years
Welcome to jbossbot on #jbosstools
by Andersen Max
FYI,
#jbosstools now has a new nice guest managed by David Lloyd named jbosstools.
It is a bot which simply will give a summary of any jira referenced in #jbosstools chat.
/max
16 years
A tip: How to speed up SVN updates
by Yahor Radtsevich
Hi All,
If you, like me, are annoyed by looooong time of trunk updates, there is a
SVN feature to skip directories you do not use. This feature is called 'Sparse
Directories<http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html>
'.
For example, to delete directory 'documentation' from your local copy of
trunk permanently, use the following command:
*svn update --set-depth empty documentation*
After this command, the documentation directory will be skipped during
further updates and switches. (To restore it back, use *--set-depth infinity
*).
Windows users may use the following batch-script to delete all documentationand
*\docs directories at once (just save as deletedocs.bat and run from trunk
directory):
@echo DELETING OF documentation...
svn update --set-depth empty documentation
@echo DELETING OF *\docs:
@FOR /f %%d IN ('dir /b /a:d') DO (
@IF EXIST %%d\docs\.svn (
@echo DELETING OF %%d\docs...
svn update --set-depth empty %%d\docs
)
)
Best Regards,
Yahor Radtsevich
16 years
Looking for examples of how to add annotations support and validation to the Java editor in Eclipse
by Brian Fitzpatrick
Hi all...
While working through some of the Web Services tooling, a great request came up for adding better annotations support for JAX-WS- and JAX-RS-annotations in the Java editor. Some of the JAX-WS annotations are already there I believe, but there's no support currently for the RESTful JAX-RS services.
What examples do we have where we've added not only support for annotations but validation so users know when they're used incorrectly?
Thanks in advance
--Fitz
_______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, SOA-P
JBoss by Red Hat
16 years
