[Hibernate-JIRA] Created: (HHH-3882) inner join fetch + Filters + one-to-many + Extra null value
by Sandeep Vaid (JIRA)
inner join fetch + Filters + one-to-many + Extra null value
-----------------------------------------------------------
Key: HHH-3882
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3882
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Reporter: Sandeep Vaid
Specify relationship in mapping using some condition not just id's.
Say i have one-to-many relationship between Product and ProductNames
Product ----> PID (PK)
ProductNames------> PID, USECODE, STARTTIME as composite ID and ENDTIME is another normal column.
Now i want to fetch product with PID='1' and USECODE='100' and STARTTIME < CURRENTTIME < ENDTIME.
CURRENTTIME value will be known at runtime.
How to specify this in mapping and fetch Product & ProductNames using eager fetching?
ANS: Using Filters, this problem can be resolved. Define filter, attach filter and enable filter. Filter supports
specifying positional parameters value at runtime.
but i got 1 problem with filters :
Suppose i have 1 product with id as 100, it has 5 ProductNames..but when we apply filter only 2 productNames remains.
When i use just "inner join fetch" with no filters, it returns me one Product object which contains List of productNames properly
populated.
BUT When i use "select distinct product" and inner join fetch" with filter, it returns one product populated with productNames
list which contains 3 elements viz. null, first filtered productName, second filtered productName..
Why productNames list contains the first element as null? This seems to be a bug..
--
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
16 years, 11 months
[Hibernate-JIRA] Commented: (HBX-575) Able to add meta information on the reveng.xml file (common configuration for all renerated classes)
by Tonté Pouncil (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-575?page=co... ]
Tonté Pouncil commented on HBX-575:
-----------------------------------
Okay, since my last post I have check out the source code of hibernate tools and updated the hibernate-reverse-engineering-3.0.dtd; which is located under tools/src/java/org/hibernate. I have modified the DTD to accepted the <meta> tag for the <key-column> tag. I have also modified the PojoPropertyAccessors.ftl free-marker templates to use my table configuration defined in my reveng.xml file to be used in create the POJOs, in regards to set-scope and get-scope.
Let me know if any of my customization can be of any use to you as I am more than willing to share what I have learned. How do I get my changes review and check into the source code?
Thanks!
Tonté
> Able to add meta information on the reveng.xml file (common configuration for all renerated classes)
> ----------------------------------------------------------------------------------------------------
>
> Key: HBX-575
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-575
> Project: Hibernate Tools
> Issue Type: Improvement
> Components: reverse-engineer
> Affects Versions: 3.1beta4
> Reporter: David Leal
> Fix For: 3.2beta9
>
> Attachments: svn-patch2.txt
>
>
> Just to add the posibility to set some meta information common to all possible generated *.hbm files, for example to set that ALL generated file will implement toString method or equal/hash code.
> A good solution whoud be to add some filter options in order to speficy the set of Tables it would apply, using regular expresion, like include nestede target from ant. Something like this:
> <meta attribute name="theAttributeName" value="theValue">
> <include name="theListOfTableToInclude"/>
> <exlude name="theListOfTablesToExclude">
> </meta>
> If it is more complicated just to add the possibility to add meta information for all possible generated files.
--
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
16 years, 11 months
[Hibernate-JIRA] Created: (HSEARCH-353) hibernate search + indexing with transaction issue
by Yan Falken (JIRA)
hibernate search + indexing with transaction issue
--------------------------------------------------
Key: HSEARCH-353
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-353
Project: Hibernate Search
Issue Type: Bug
Components: engine
Affects Versions: 3.1.0.GA
Reporter: Yan Falken
Hi,
I have the following problem with indexing in transaction with hibernate
search: in case the transaction is opened and I want to perform multiple
work types - only one type is actually performed after the commit and the others are
ignored; example:
TransactionManager tm = new DummyTransactionManager();
tm.begin();
SEntity se1 = new SEntity(10, "first", "second", true);
Work delete = new Work(se1, "100", WorkType.DELETE);
Work add = new Work(se1, "100", WorkType.ADD);
Ctx ctx = new Ctx(tm.getTransaction());
searchFactory.getWorker().performWork(delete, ctx);
searchFactory.getWorker().performWork(add, ctx);
tm.commit();
only DELETE is performed - ADD is ignored
log:
2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [hibernate.search.default.indexBase] value: /tmp/c1idx
2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [default.indexBase] value: /tmp/c1idx
2009-03-23 13:45:02,341 DEBUG main| BuilderIndexedEntity| Field selection in projections is set to false for entity problems.SEntity.
2009-03-23 13:45:02,502 DEBUG pool-1-thread-1| PerDPQueueProcessor| Skipping usage of an IndexWriter for updates
2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Locking Workspace (or waiting to...)
2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Workspace lock aquired.
// opened
2009-03-23 13:45:02,503 DEBUG pool-1-thread-1| PerDPQueueProcessor| Opening an IndexReader for update
2009-03-23 13:45:02,503 TRACE pool-1-thread-1| Workspace| IndexReader opened
// only remove
2009-03-23 13:45:02,503 TRACE pool-1-thread-1| eleteExtWorkDelegate| Removing class problems.SEntity#100 by id using an IndexReader.
2009-03-23 13:45:02,539 TRACE pool-1-thread-1| Workspace| IndexReader closed
2009-03-23 13:45:02,539 TRACE pool-1-thread-1| PerDPQueueProcessor| Unlocking Workspace
I digged into the code a little bit and there is class method:
org.hibernate.search.engine.DocumentBuilderIndexedEntity.addWorkToQueue() which is in it's beginning iterating the existing queue to avoid unecessary duplicated works
if ( workType == WorkType.DELETE ) { //TODO add PURGE?
//DELETE should have precedence over any update before (HSEARCH-257)
//if an Add work is here, remove it
//if an other delete is here remember but still search for Add
if ( luceneWork instanceof AddLuceneWork ) {
toDelete.add( luceneWork );
}
else if ( luceneWork instanceof DeleteLuceneWork ) {
duplicateDelete = true;
}
}
else {
//we can safely say we are out, the other work is an ADD
return;
}
I believe that return should be changed to continue. I did several tests and after the change it can handle ADD/DELETE works in one queue.
There should be ability to in single transaction perform multiple work types as there is no way how to control the client to perform just one work type.
--
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
16 years, 11 months