Closed GoogleCodeExporter closed 9 years ago
I'm getting this to. Trying to debug it, but because it's a plugin it's almost
impossible to debug in eclipse. There's no guide on how to debug plugins.
Original comment by rqu...@ebstrada.com.au
on 19 Oct 2011 at 6:07
I can replicate it both on the live server and locally.
Original comment by rqu...@ebstrada.com.au
on 19 Oct 2011 at 6:08
Nevermind the debug comment.. figured out how to debug it now.
Original comment by rqu...@ebstrada.com.au
on 19 Oct 2011 at 6:20
Looks like it's something to do with query cache.
Original comment by rqu...@ebstrada.com.au
on 19 Oct 2011 at 6:29
Line 103 of CacheServiceImpl:
result.putAll(cache.getAll(memcacheKeys));
cache.getAll(memcacheKeys) returns null and consequently breaks everything.
Original comment by rqu...@ebstrada.com.au
on 19 Oct 2011 at 6:51
To make a long story short, I think the fix is to go into the two DAO
Implementation files in the registration plugin and remove the second argument
(the custom table name) from the call to super's constructor.
The query cache code uses EntityUtil.getKind(Class clazz) to add the name,
which pays no attention to the DAO's kind string member (which is the custom
table name).
If you remove the argument, it uses the name of the class as the table name
(which is what getKind() in EntityUtil provides.
One place I can find the use of EntityUtil.getKind() where it shouldn't be used
is in QueryCacheImpl.getCachedQueryResult(). It should be looking up the DAO's
kind string member variable value, but instead it is looking at the class name
for the key it uses to store the data to memcache.
Original comment by rqu...@ebstrada.com.au
on 19 Oct 2011 at 10:45
To further confirm that this only happens to the register plugin, public
BaseDaoImpl(Class aClass, String aKind) is only ever called from the register
plugin, when it should be just calling BaseDaoImpl(Class aClass)
Original comment by rqu...@ebstrada.com.au
on 19 Oct 2011 at 10:49
Just one more comment (I know I've posted enough already).
Automatically using a class name as the table name seems to be a bad solution
going forward. All the DAOs in Vosao seem to be doing this.
What if someone wanted to write a Vosao plugin and use something like proguard
to obfuscate the code? The table names would be aa ab ac ad etc.
Original comment by rqu...@ebstrada.com.au
on 19 Oct 2011 at 10:56
Removing the second argument for the DAO's has worked for me. I haven't had any
problems since migrating the tables to the new name and reinstalling a
recompiled register plugin.
Original comment by rqu...@ebstrada.com.au
on 19 Oct 2011 at 11:17
The same problem as you, but I do not know how to fix. Could you provide a
modified plugin to download?
Thanks.
Original comment by SlynkoNi...@gmail.com
on 12 Feb 2012 at 7:30
Original comment by kinyelo@gmail.com
on 12 Feb 2012 at 8:39
This issue was closed by revision r1149.
Original comment by kinyelo@gmail.com
on 12 Feb 2012 at 8:39
Original issue reported on code.google.com by
mikemyer...@gmail.com
on 16 Oct 2011 at 7:54