[Hibernate-JIRA] Created: (HSEARCH-74) Ability to extract meta-information about search result
by Christian Bauer (JIRA)
Ability to extract meta-information about search result
-------------------------------------------------------
Key: HSEARCH-74
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-74
Project: Hibernate Search
Issue Type: New Feature
Components: engine
Affects Versions: 3.0.0.beta2
Reporter: Christian Bauer
I need the score of a hit. The only time when this information is available seems to be in FullTextQueryImpl.java in line 219:
for ( int index = first; index <= max; index++ ) {
Document document = hits.doc( index );
infos.add( extractor.extract( document ) );
}
Not sure what the API would look like and what other information from each Hit object would be considered metadata, except the score and maybe boost. Maybe this can be covered with magic projection properties, something like:
org.hibernate.search.FullTextQuery query = s.createFullTextQuery( luceneQuery, Book.class );
query.setIndexProjection( "hsearchScore", "this" );
List results = query.list();
Object[] firstResult = (Object[]) results.get(0);
Double score = firstResult[0];
Book book = firstResult[1];
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[Hibernate-JIRA] Created: (ANN-641) @OneToMany disables @OnDelete on @ManyToOne
by Christian Bauer (JIRA)
@OneToMany disables @OnDelete on @ManyToOne
-------------------------------------------
Key: ANN-641
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-641
Project: Hibernate Annotations
Issue Type: Bug
Components: binder
Affects Versions: 3.3.0.ga
Reporter: Christian Bauer
This mapping:
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "PARENT_NODE_ID", nullable = true)
@org.hibernate.annotations.OnDelete(action = org.hibernate.annotations.OnDeleteAction.CASCADE)
protected Node parent;
Generates the following correct DDL:
alter table NODE
add index FK24A602FC03E1AA (PARENT_NODE_ID),
add constraint FK24A602FC03E1AA
foreign key (PARENT_NODE_ID)
references NODE (NODE_ID)
on delete cascade;
However, if you add a bidirectional collection with @OneToMany:
@OneToMany(mappedBy = "parent")
private List<Node> children = new ArrayList<Node>();
the DDL is missing the "on delete cascade" option. Workaround is moving the @OnDelete onto the @OneToMany:
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "PARENT_NODE_ID", nullable = true)
protected Node parent;
@OneToMany(mappedBy = "parent")
@org.hibernate.annotations.OnDelete(action = org.hibernate.annotations.OnDeleteAction.CASCADE)
private List<Node> children = new ArrayList<Node>();
This is not intuitive, and if the binding can't be changed, needs to be documented.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[Hibernate-JIRA] Reopened: (HBX-700) Custom type mapping is not possible when reverse-engineering Oracle TIMESTAMP(3) types
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-700?page=co... ]
Max Rydahl Andersen reopened HBX-700:
-------------------------------------
can't find the duplicate issue so lets transform this one to what it is really about
> Custom type mapping is not possible when reverse-engineering Oracle TIMESTAMP(3) types
> --------------------------------------------------------------------------------------
>
> Key: HBX-700
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-700
> Project: Hibernate Tools
> Issue Type: Bug
> Components: reverse-engineer
> Environment: 3.2 svn, Oracle 10g, Oracle JDBC Driver version - "10.2.0.1.0"
> Reporter: Genandiy Donchyts
> Attachments: hbm2java.cfg.xml, schema.sql, Test.hbm.xml
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> When reverse-engineering Oracle database containint column with TIMESTAMP(3) type it is not recognized as a TIMESTAMP and "serializable" type is used instead of timestamp. This happens because of the bug in Oracle JDBC driver since it returns OTHER (1111) instead of TIMESTAMP(93).
> When type-mapping is provided in the form:
> <type-mapping>
> <sql-type jdbc-type="TIMESTAMP(3)" hibernate-type="timestamp" />
> </type-mapping>
> ... it is not used because hibernate can't find TIMESTAMP(3) JDBC data type.
> JDBCReader.java, processBasicColumns(Table table, ProgressListener progress):
> ...
> //TODO: column.setSqlType(sqlTypeName); //this does not work 'cos the precision/scale/length are not retured in TYPE_NAME
> //column.setSqlType(sqlTypeName);
> ...
> it would be nice to have this sqlTypeName set to Column and used during comparison with <type-mapping>, then mapping from "TIMESTAMP(3)" to "timestamp" would work. Currently only 1111 ("OTHER") is passed to Column and as result column does not know anything about "TIMESTAMP(3)"
> -----
> To reproduce an issue try to create simple Oracle database with one table:
> create table test(id TIMESTAMP(3));
> and run reverse-engineering task over it.
> ------
> HACK: custom handling of TIMESTAMP(*) types:
> Modify JDBCReader.java:
> private void processBasicColumns(Table table, ProgressListener progress) { // get the columns
> ...
> String sqlTypeName = (String) columnRs.get("TYPE_NAME");
> String columnName = (String) columnRs.get("COLUMN_NAME");
> // HACK: custom handling of TIMESTAMP(*)
> if(sqlTypeName.startsWith("TIMESTAMP")) {
> sqlType = java.sql.Types.TIMESTAMP;
> }
> ...
> See also forum post: http://forum.hibernate.org/viewtopic.php?t=961625&start=0&postdays=0&post...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[Hibernate-JIRA] Updated: (HBX-700) Custom type mapping is not possible when reverse-engineering types that are not mapped uniquely to java.sql.Types
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-700?page=co... ]
Max Rydahl Andersen updated HBX-700:
------------------------------------
Summary: Custom type mapping is not possible when reverse-engineering types that are not mapped uniquely to java.sql.Types (was: Custom type mapping is not possible when reverse-engineering Oracle TIMESTAMP(3) types)
> Custom type mapping is not possible when reverse-engineering types that are not mapped uniquely to java.sql.Types
> -----------------------------------------------------------------------------------------------------------------
>
> Key: HBX-700
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-700
> Project: Hibernate Tools
> Issue Type: Bug
> Components: reverse-engineer
> Environment: 3.2 svn, Oracle 10g, Oracle JDBC Driver version - "10.2.0.1.0"
> Reporter: Genandiy Donchyts
> Attachments: hbm2java.cfg.xml, schema.sql, Test.hbm.xml
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> When reverse-engineering Oracle database containint column with TIMESTAMP(3) type it is not recognized as a TIMESTAMP and "serializable" type is used instead of timestamp. This happens because of the bug in Oracle JDBC driver since it returns OTHER (1111) instead of TIMESTAMP(93).
> When type-mapping is provided in the form:
> <type-mapping>
> <sql-type jdbc-type="TIMESTAMP(3)" hibernate-type="timestamp" />
> </type-mapping>
> ... it is not used because hibernate can't find TIMESTAMP(3) JDBC data type.
> JDBCReader.java, processBasicColumns(Table table, ProgressListener progress):
> ...
> //TODO: column.setSqlType(sqlTypeName); //this does not work 'cos the precision/scale/length are not retured in TYPE_NAME
> //column.setSqlType(sqlTypeName);
> ...
> it would be nice to have this sqlTypeName set to Column and used during comparison with <type-mapping>, then mapping from "TIMESTAMP(3)" to "timestamp" would work. Currently only 1111 ("OTHER") is passed to Column and as result column does not know anything about "TIMESTAMP(3)"
> -----
> To reproduce an issue try to create simple Oracle database with one table:
> create table test(id TIMESTAMP(3));
> and run reverse-engineering task over it.
> ------
> HACK: custom handling of TIMESTAMP(*) types:
> Modify JDBCReader.java:
> private void processBasicColumns(Table table, ProgressListener progress) { // get the columns
> ...
> String sqlTypeName = (String) columnRs.get("TYPE_NAME");
> String columnName = (String) columnRs.get("COLUMN_NAME");
> // HACK: custom handling of TIMESTAMP(*)
> if(sqlTypeName.startsWith("TIMESTAMP")) {
> sqlType = java.sql.Types.TIMESTAMP;
> }
> ...
> See also forum post: http://forum.hibernate.org/viewtopic.php?t=961625&start=0&postdays=0&post...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[Hibernate-JIRA] Created: (HHH-2743) NOT NULL columns for "nullable=false" properties not always correct
by Andreas Schildbach (JIRA)
NOT NULL columns for "nullable=false" properties not always correct
-------------------------------------------------------------------
Key: HHH-2743
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2743
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1
Reporter: Andreas Schildbach
When Hibernate creates a schema for a "table-per-class-hierarchy" mapping, it does not take into account that some properties might only exist on single branches of that hierarchy.
Have a look at the attached example (Maven2: mvn eclipse:eclipse to create an eclipse project).
Classes A and B extend Base. Class A defines a property "a", and B defines b - both with "nullable = false". Hibernate then creates a "NOT NULL" column for those properties. I think this is not correct, because even if instances of A always have that property set it might still be NULL (for instances of B) in the database due to the table-per-class-hierarchy mapping.
Here is what happens if you start "ProblemTest":
"Attempt to insert null into a non-nullable column: column: B table: BASE in statement [insert into Base (id, a, class) values (null, ?, 'a')]"
This is the schema that has been created by Hibernate for HSQLDB:
create table Base
(
class varchar(31) not null,
id integer generated by default as identity (start with 1),
a integer not null,
b integer not null,
primary key (id)
)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[Hibernate-JIRA] Created: (HHH-2742) Columns in resultset of stored procedure call are being aliassed
by Martin van Dijken (JIRA)
Columns in resultset of stored procedure call are being aliassed
----------------------------------------------------------------
Key: HHH-2742
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2742
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.2
Environment: Hibernate version 3.2.2, Sybase
Reporter: Martin van Dijken
I have a call to a stored procedure that returns a result set, mapped as:
<sql-query name="loadUser" callable="true">
<return class="User">
<return-property name="id" column="userId"/>
<return-property name="fullName" column="usersFullNameAsCitedWhenRegistering"/>
</return>
<query-param name="userId" type="long"/>
{call loadUser(:userId)}
</sql-query>
I get the error:
invalid column name 'usersFul5_12_0_'
It looks like although I mapped the field fullName in my user object to the field usersFullNameAsCitedWhenRegistering in the resultset, Hibernate is determining that usersFullNameAsCitedWhenRegistering is too long and aliasses that to usersFul5_12_0_. The resultset however does not contain usersFul5_12_0_.
Can this be fixed somehow? If (probably) not, can you please document this in the "calling stored procedure section" to save others a few hours of searching?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months