Hi, again thanks for answers, I will do for now pretty much what Andrey suggested - do subsequent commits as this is "one-time" operation and when the network will grow I will again populute the range in db (no more than 10k hosts)
@Ari - yeah I overlooked this when you said it first time, but as I've already said, this table is mere list/enumeration for now and needs to be populated once per db lifetime Cheers, -- Marek Šabo On 02/03/2010 01:44 PM, Andrey Razumovsky wrote: > Actually, no. If you need to index data by IP, you just add indexing by IP > column. If you want to perform in future meaningful sort by meaningless IP, > you will have to think about such cases as changes the IP column - then the > order might break. Answering your question, if you really think you need > control over PK values, you either use custom PKs (and generate them > yourself), or, if the speed isn't priority, do many sequent commits instead > of one (if the logic of your app allows you) > > 2010/2/3 Marek Šabo <ms...@buk.cvut.cz> > > >> Thank you all for your ideas, my progress: >> >> >> >> 1) Is there any way to sort varchar fields which happen to numbers, more >> >>> precisely ipv4s? >>> query.addOrdering(Ip4Address.IP_ADDRESS_PROPERTY, SortOrder.ASCENDING); >>> This of course sets the hundreds as first in line, any tips on some >>> custom sorting? >>> >>> >>> >> I just implemented custom comparator and added the result list from query >> to treeset - anyway the IPs are unique. >> >> >>> 2) Is there any way how to override this mechanism in order to preserve >>> order of inserted rows? >>> >>> >>> >>> >> This one I can't really cope with. Of course I could fill it in ten other >> ways which will preserve the order of inserted rows, so really, haven't any >> of you ever needed or wanted the data to be indexed by auto-generated pk in >> order you add them to context while in persisting phase? Because that would >> nicely solve issue #1 as well because the IPs would be sorted according to >> pk. This is collateral functionality that's why it isn't designed as OOP >> would preach. >> >> Regards, >> >> Marek >> >> > > >
