[#TRAILS-55] Duplicate users showing up accidentally - impact from merge 582

Trails

Duplicate users showing up accidentally - impact from merge 582

Created: 05/Jun/07 11:15 AM Updated: 07/Apr/08 11:34 AM

Component/s:

None

Affects Version/s:

1.1.0

Fix Version/s:

1.1.0

Time Tracking:

Not Specified

Environment:

XP Pro, MySQL, HSql

Description

« Hide

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

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)

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

Ken in nashua added a comment - 05/Jun/07 11:28 AM

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

[ Permalink | « Hide ]

Ken in nashua added a comment - 14/Jun/07 12:33 PM

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.

[ Permalink | « Hide ]

Ken in nashua added a comment - 14/Jun/07 12:36 PM

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.

[ Permalink | « Hide ]

Kalle Korhonen added a comment - 14/Jun/07 01:13 PM

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.

[ Permalink | « Hide ]

Ken in nashua added a comment - 14/Jun/07 01:41 PM

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

[ Permalink | « Hide ]

Ken in nashua added a comment - 14/Jun/07 01:48 PM

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

[ Permalink | « Hide ]

Ken in nashua added a comment - 14/Jun/07 01:50 PM

Additionally...

I don't see a need for

HibernateListPage.JAVA
public void reloadInstances()

{ // do nothing; }

Maybe you can consider removing it.

[ Permalink | « Hide ]

Ken in nashua added a comment - 14/Jun/07 01:57 PM

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

[ Permalink | « Hide ]

Kalle Korhonen added a comment - 17/Jun/07 12:08 AM

Fixed in HibernatePersistenceImpl