Trails

Duplicate users showing up accidentally - impact from merge 582

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1.0
  • Fix Version/s: 1.1.0
  • Component/s: None
  • Labels:
    None
  • Environment:
    XP Pro, MySQL, HSql
  • Number of attachments :
    0

Description

Upon bootstrap, multiple users (users that come with trails by default) are showing up in the User table.

Login as admin/admin
List Users

this is what renders on the user-interface

I do not know why thes eare not being constrained by ID... it appears the dups have the same ID

1 user Foo Bar true true true true
1 user Foo Bar true true true true
2 admin Admin Admin true true true true
2 admin Admin Admin true true true true
2 admin Admin Admin true true true true
3 anonymous Anonymous Anonymous true true true true

For my local build I added Anonymous user (and this is checked in)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ken in nashua added a comment -

Well it's important to note that the database is fine.

It has the proper amount of users

Additionally, the join table for roles is also setup properly too.

This appears to be a collection rendering issue

Show
Ken in nashua added a comment - Well it's important to note that the database is fine. It has the proper amount of users Additionally, the join table for roles is also setup properly too. This appears to be a collection rendering issue
Hide
Permalink
Ken in nashua added a comment -

Additionally, if you configure a UserDetails pojo with more than one role... it shows up in the ObjectTable not only for as many roles there are but for as many duplicates roles there are too.

So the duplicates are being cloned/replicated to the rendering by multiple factors.

Show
Ken in nashua added a comment - Additionally, if you configure a UserDetails pojo with more than one role... it shows up in the ObjectTable not only for as many roles there are but for as many duplicates roles there are too. So the duplicates are being cloned/replicated to the rendering by multiple factors.
Hide
Permalink
Ken in nashua added a comment -

This does not appear to affect EditCollection.

It appears to be isolated to all ObjectTable renderings...

So this may be HibernateListPage issue... my best guess.

I will take a look.

Show
Ken in nashua added a comment - This does not appear to affect EditCollection. It appears to be isolated to all ObjectTable renderings... So this may be HibernateListPage issue... my best guess. I will take a look.
Hide
Permalink
Kalle Korhonen added a comment -

Are you using your own criteria or relying on the default implementation? A call criteria.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY) needs to be added; let me know if it's the default implementation and I'll add it.

Show
Kalle Korhonen added a comment - Are you using your own criteria or relying on the default implementation? A call criteria.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY) needs to be added; let me know if it's the default implementation and I'll add it.
Hide
Permalink
Ken in nashua added a comment -

Hi kalle,

I wondered why
if ( getInstances() != null ) getInstances().clear();
was futile...

But it seems like alot of overhead under the hood.

Anyway, I tested it and it works.

HibernateListPage.JAVA
getCriteria().setResultTransformer(DetachedCriteria.DISTINCT_ROOT_ENTITY);

inside the ctor...

You can checkin and close.

Thanks

Show
Ken in nashua added a comment - Hi kalle, I wondered why if ( getInstances() != null ) getInstances().clear(); was futile... But it seems like alot of overhead under the hood. Anyway, I tested it and it works. HibernateListPage.JAVA getCriteria().setResultTransformer(DetachedCriteria.DISTINCT_ROOT_ENTITY); inside the ctor... You can checkin and close. Thanks
Hide
Permalink
Ken in nashua added a comment -

Kalle, same thing is happening within the palette.

Can you nail that too... as well as other spots?

Let me know if you need assistance.
thanks
Ken

Show
Ken in nashua added a comment - Kalle, same thing is happening within the palette. Can you nail that too... as well as other spots? Let me know if you need assistance. thanks Ken
Hide
Permalink
Ken in nashua added a comment -

Additionally...

I don't see a need for

HibernateListPage.JAVA
public void reloadInstances()

{ // do nothing; }

Maybe you can consider removing it.

Show
Ken in nashua added a comment - Additionally... I don't see a need for HibernateListPage.JAVA public void reloadInstances() { // do nothing; } Maybe you can consider removing it.
Hide
Permalink
Ken in nashua added a comment -

Actually if you can nip this in

@Transactional
public <T> List<T> getAllInstances(final Class<T> type)

{ DetachedCriteria criteria = DetachedCriteria.forClass(Utils.checkForCGLIB(type)); return getHibernateTemplate().findByCriteria(alterCriteria(type,criteria) ); }

that will prevent edit nightmare

Show
Ken in nashua added a comment - Actually if you can nip this in @Transactional public <T> List<T> getAllInstances(final Class<T> type) { DetachedCriteria criteria = DetachedCriteria.forClass(Utils.checkForCGLIB(type)); return getHibernateTemplate().findByCriteria(alterCriteria(type,criteria) ); } that will prevent edit nightmare
Hide
Permalink
Kalle Korhonen added a comment -

Fixed in HibernatePersistenceImpl

Show
Kalle Korhonen added a comment - Fixed in HibernatePersistenceImpl

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.