Selena hibernate support - also for regular .hbm files? (no JPA)


Are there any details available what the "Hibernate" feature on the roadmap
is supposed to mean?
Let's say I'm a plain Hibernate 3.x user, no JPA involved. Will selena do
anything for me in that scenario?


12 comments
Comment actions Permalink

Hello Taras,

Hibernate 3.0 configuration and mapping XMLs will be supported
just like JPA persistence.xml and orm descriptors.

Regards,
Gregory Shrago


Taras Tielkes wrote:


Are there any details available what the "Hibernate" feature on the
roadmap is supposed to mean?
Let's say I'm a plain Hibernate 3.x user, no JPA involved. Will selena
do anything for me in that scenario?

0
Comment actions Permalink

Hello Gregory,

Hibernate 3.0 configuration and mapping XMLs will be supported just
like JPA persistence.xml and orm descriptors.


When will we see the first parts of this functionality in the EAP?
Do you have a list of specific features planned for "plain Hibernate 3.0"
support?


0
Comment actions Permalink

Hello Taras,

The initial version will appear in one of the next EAP.

Diagram, object tree, XML and java highlighting,
HQL highlighting and a number of intention actions.


Taras Tielkes wrote:

Hello Gregory,

>> Hibernate 3.0 configuration and mapping XMLs will be supported just
>> like JPA persistence.xml and orm descriptors.


When will we see the first parts of this functionality in the EAP?
Do you have a list of specific features planned for "plain Hibernate
3.0" support?

0
Comment actions Permalink

If I understand correctly, that will cover most of the current Hibero plugin
functionality, correct?


0
Comment actions Permalink

It looks like yes, as far as hibernate 3.0 is concerned.
I'm not sure if query executors will be available, though.

Taras Tielkes wrote:

If I understand correctly, that will cover most of the current Hibero
plugin functionality, correct?

0
Comment actions Permalink

Hello Gregory,

What do you think of the next two features:
1) "Synthetic datasource" based on parsed SQL DDL files.
In essence, scan for 'create table' statements in a set of .sql files
that I specify, and build a database structure model out of that.
Benefits would be:
-I can develop without a connection to the real database
-Easy source control: model mutations work directly on the DDL files
I checked out from source control
2) HQL language injection into specific String literals in Java code.
The big majority of our HQL code is embedded in Java (spring DAOs in
fact).
With some mimimal DFA it should be possible to only inject language into
string literals that are passed into specific API methods.
Or course, concatenations that include variables will not be supported
(only "pure" single/multiline string liternals)


0
Comment actions Permalink

1) At the moment DataSource info is stored in an ipr file and one can
easily change it without the real DB connection.
We can think of SQL DDL or some other way of specifying it.

2) HQL injection will be supported in java as well as in XML.

Taras Tielkes wrote:

Hello Gregory,

What do you think of the next two features:
1) "Synthetic datasource" based on parsed SQL DDL files.
In essence, scan for 'create table' statements in a set of .sql files
that I specify, and build a database structure model out of that.
Benefits would be:
-I can develop without a connection to the real database
-Easy source control: model mutations work directly on the DDL files
I checked out from source control
2) HQL language injection into specific String literals in Java code.
The big majority of our HQL code is embedded in Java (spring DAOs in
fact).
With some mimimal DFA it should be possible to only inject language
into string literals that are passed into specific API methods.
Or course, concatenations that include variables will not be
supported (only "pure" single/multiline string liternals)

0
Comment actions Permalink

Hello Gregory,

1) At the moment DataSource info is stored in an ipr file and one can
easily change it without the real DB connection.
We can think of SQL DDL or some other way of specifying it.

IDEA-11381 :)

2) HQL injection will be supported in java as well as in XML.

How will you determine places to inject? I hope not by requiring an annotation..?


0
Comment actions Permalink

Taras Tielkes wrote:

Hello Gregory,

>> 1) At the moment DataSource info is stored in an ipr file and one can
>> easily change it without the real DB connection.
>> We can think of SQL DDL or some other way of specifying it.

IDEA-11381 :)


I got it :)

>> 2) HQL injection will be supported in java as well as in XML.

How will you determine places to inject? I hope not by requiring an
annotation..?


By recognizing Hibernate API call, I think.

0
Comment actions Permalink

Or via the IntelliLang plugin hopefully.

0
Comment actions Permalink

Hello Gregory,

>> How will you determine places to inject? I hope not by requiring an
>> annotation..?
>>

By recognizing Hibernate API call, I think.


1) In that case there are also relevant Spring APIs to recognize.
Should I be adding requests for such things to JIRA already?

2) When you say "by recognizing Hibernate API", will that include patterns
like the following?

a) local variable string literal
-


public List doSomething(int i) {
final String hql =
"from Foo foo " +
"where foo.bar = 123 ";
return someApi.list(hql);
}
-


b) Same as above, but HQL query is stored in a private static final field
of the containing class


0
Comment actions Permalink

Hello Gregory,

It looks like yes, as far as hibernate 3.0 is concerned. I'm not sure
if query executors will be available, though.


I've tried the HQL injection in #6708, and these are my comments/questions
so far:
1) I have entered IDEA-11599. Most of our HQL is in this format, and having
support for this would greatly increase the value of the Hibernate plugin.
2) When can we expect multiline string literals - IDEADEV-9347?
3) I think something like IntelliLang "Quick Edit Language" would make a
lot of sense for embedded HQL.
4) Since I'm always writing HQL by "trial-and-error", having executor support
would be very nice. (And some way to see the generated raw SQL would be
another plus)

Perhaps a variation of "Quick Edit Language" could be integrated into the
core language support:
-Some languages could "contribute" extra tabs (execute HQL, view translated
SQL, ...)
-It should support refactorings (IntelliLang Quick Edit does not support
Refactor->Rename)

Regards,
-tt


0

Please sign in to leave a comment.