Как осуществить субж?
Например

Что мне нужно:
Возможность выдернуть юзера по ИД и по Сессии, будут какие предложения? А то я уже совсем запутался...

Используй MultiKey из Jakarta Commons Collections.

Гм, а сделать свой Key объект, который состоит из инта и стринга?
Определив hashcode, equals() 

И по сессии И по айдишнику - тогда можно просто сделать свой объектик, как и сказал chief39, а вот если ИЛИ по сессии ИЛИ по айдишнику, тогда не знаю, видимо, ка сказал LSD ... Тоже гляну на это мультикей

ПыСЫ
в любом случае кто мешает при добавлении пихать в два хэшмапа, а при поиске пользоваться нужным

Это сообщение отредактировал(а) y3u - 12.2.2007, 17:16

y3u, 
Нужно ИЛИ по сессии, ИЛИ по айди.
Multikey не подходит, т.к  там сразу по обоим критериям.
Насчет двух  хешмапов думал, но подумал, что есть более правильное решение.

Так И или ИЛИ? 
Если ИЛИ, то можно и одной HashMap обойтись.

Но будет геморой с удалением значений. Например мы хотим удалить запись по ID, но нужно также будет найти его сессию, чтобы удалить и ее.

а вот и нельзя  Есть известное утверждение, что у двух идентичных объектов должен быть идентичный хешкод, но, если мы имеем два идентичных хешкода - отсюда НЕ следует, что объекты идентичные. Вполне легальны ситуации: коллекция не типизированная - значит хеши по стринге и по интеджеру могут совпасть, а если типизированная, то так сделать не даст компилятор 

Это сообщение отредактировал(а) y3u - 13.2.2007, 13:20

И какое это имеет отношение, к тому что я сказал?

прямое



скажем, в 1.4 SDK посмотри как работает get(Object key) у HashMap... у тебя медленный код, т.к. хеши id и value могут быть одинаковыми, а реально объекты, находящиеся по этим ключам - разные

вобщем, ладно... это оффтоп 

Это сообщение отредактировал(а) y3u - 13.2.2007, 15:22

Вообще то, я прелагал искать value или по id, или по name  
И хеш код value в данном случае вообще неважен.

Добавлено @ 16:04 

Я знаю как работает HashMap. Совпадение хешей маловероятно, но не смертельно, в реальных задачах они все равно совпадают.

Почему они вдруг разные? И там и там указатель на один и тот же обьект.

Пишешь что-то вроде:


Добавлено @ 16:06 

"Медленность" зависит от соотношения размера таблицы к количеству элементов в ней. Тут Ява сама подберёт оптимальную величину.

да блин, я описАлся, я имел в виду, конечно, name, а не value... Я вообще только о ключх говорю и все  Не буду оффтопить дальше, скажу лишь, по поводу реальности задачи, что вероятность совпадения хешей и id и name в данном случае велика, причем вероятность увеличивается с ростом количества пользователей. Просто имеет смысл избегать нежелательных проблем с производительностью в тех случаях, где их реально можно избегать заранее просто и легко. Там же сначала берется хеш, достается индекс из таблицы, потом икуалс смотрится, если не совпадает ьерется следующее совпадение по хешу... Вы же не храните в одной банке соль и сахар на кухне...

Это сообщение отредактировал(а) y3u - 13.2.2007, 16:23

Не больше, чем совпадение двух разных name.


Не верно. С увеличением количества пользователей наша таблица будет расширятся и уменьшать таким образом вероятность совпадений.
(Размер кстати можно и изначально побольше задать)

Для практически равномерного распределения размер таблицы должен быть примерно N+20% где N - количество элементов хранимых таблице. Что это за объекты - не важно


Нет, но книги разных авторов за разное время спокойно стоят на одной полке. И name и id - то и другое для хэштаблицы - объекты с калькулируемым идентификатором.

Написал класс, по совету chief39, 


Добавляю в HashMap так:


Как мне бонально проверить на наличие сессии?

не помогает

аналогично

Это сообщение отредактировал(а) Opik - 27.2.2007, 23:28

При такой реализации DoubleKey - никак. Точнее, никак за счёт containsKey. Простой перебор множества ключей сработает, но это простой перебор. В качестве заплатки сработает, если будешь пихать в мапу "пустышку" именно для возможности поиска по сессии:

Искать тогда так:

null вместо идентификатора пихать нельзя, т.к. будет падать на NullPointer.

nornad, 
Если делать put - 0, тогда смысл во всей это байде отпадает совсем.

А, никак  Два DoubleKey будут равны только в случае совпадения и id и session. (ты просто реализовал свой MultiKey)

Единственный нормальный выход в данной ситуации - это 2 Map-а.

А ты не думал, что ты хочешь слишком уж много? Тебе требуется, чтобы мапа различала ключи с разными id и session при вставке, и НЕ различала их по id при поиске ключа в мапе. Так не бывает. Это сродни тому, чтобы определить, есть ли в мапе по интам чётные ключи. Надо - перебери мапу или добавляй свои "пустышки". Не нужна такая "байда" - не ломай голову.   

Вернее даже одним можно обойтись 

LSD, 
Коим образом?

Да очень просто:

Единственная проблема это метод remove() но тут уж ничего не поделаешь, кроме как завести еще один Map для установки соответствия id и session.

LSD, 
В этом случае все равно лучше уже 2 мапа. Впрочем остановился на 2-ух, пофиг 

Значит считаем вопрос решенным?

Угу, уже пометил 

Не совсем верно, потому что если у тебя будет два одинаковых идентификатора в разных сессиях или два разных идентификатора для одной сессии, то в мапе произойдёт наложение. В общем, мапа будет хранить не совсем то, что хочется.   

Вообще-то идентификатор должен быть уникальным, иначе никакого поиска по нему не может быть.
А два одинаковых идентификатора для одной и той же сессии, это хотя и очень странное решение, но работать будет.

Видимо, ты этого не заметил. ;)

Видимо ты не заметил  

Если ид или сессия не уникальны, то как ты предлагашь по ним искать?

Да, действительно не заметил этого. В памяти держалась лишь первоначальная задача - уникальность по двойному ключу, а в мапе надо было проверить, нет ли ключей с конкретной сессией.