rdp / google_hash

wrapper for google's hash functions, for ruby
BSD 3-Clause "New" or "Revised" License
92 stars 16 forks source link

Can't marshal / serialize GoogleHash object #21

Open danyal opened 11 years ago

danyal commented 11 years ago

Is there any way to marshall / searialze a google hash object? I would ideally like to create the hash, store it in a db, and then recreate it from the db.

rdp commented 11 years ago

Not yet except maybe iterating over each key/value and writing them to disk, then vice-versa. google_hash does have some "serialize" code underneath I should look at it to see if it's easy...

On Mon, Mar 4, 2013 at 12:32 AM, Danyal Anik notifications@github.comwrote:

Is there any way to marshall / searialze a google hash object? I would ideally like to create the hash, store it in a db, and then recreate it from the db.

— Reply to this email directly or view it on GitHubhttps://github.com/rdp/google_hash/issues/21 .

floere commented 9 years ago

I'd be extremely interested in this, as I'd like to use this lib for my search engine, http://pickyrb.com/ – sorry that this is just a +1.

rdp commented 9 years ago

Could somebody please elaborate on what their use case is for this? They need a super fast serial/deserialize to disk?

On Sun, Feb 1, 2015 at 5:36 AM, Florian R. Hanke notifications@github.com wrote:

I'd be extremely interested in this, as I'd like to use this lib for my search engine, http://pickyrb.com/ – sorry that this is just a +1.

— Reply to this email directly or view it on GitHub https://github.com/rdp/google_hash/issues/21#issuecomment-72363084.

floere commented 9 years ago

In Picky, I'd like to be able to dump/load the Hash-based indexes to/from disk. Currently, I could use #each to dump to disk, and then load it again – however, if the faster version was available, I'd gladly use that.

AlexRevin commented 9 years ago

Yes, I am using it the same way: calculating millions of combinations and storing them in google_hash while in app. Cannot really save them anywhere because google_hash is not dupable. I want to store results in Daybreak and there's no other way to get it there rather than iterating key-by-key. +1 a lot!

rdp commented 9 years ago

OK are you folks all just looking for dumping native types or Ruby objects?

On Mon, Mar 16, 2015 at 4:46 PM, Alex notifications@github.com wrote:

Yes, I am using it the same way: calculating millions of combinations and storing them in google_hash while in app. Cannot really save them anywhere because google_hash is not dumpable. +1 a lot!

— Reply to this email directly or view it on GitHub https://github.com/rdp/google_hash/issues/21#issuecomment-81972366.

floere commented 9 years ago

@rdp For me it's not as important how they are stored, just that they can be reloaded.

rdp commented 9 years ago

what type of objects, though, does this include ruby objects or just native ones [storing ruby objects is far more tricky]

On Thu, Mar 19, 2015 at 10:25 AM, Florian R. Hanke <notifications@github.com

wrote:

@rdp https://github.com/rdp For me it's not as important how they are stored, just that they can be reloaded.

— Reply to this email directly or view it on GitHub https://github.com/rdp/google_hash/issues/21#issuecomment-83650905.

AlexRevin commented 9 years ago

I think conversion of native objects is enough. Storing custom objects requires marshaling which is not a good idea at all.

floere commented 9 years ago

@rdp By "native", do you mean String/Numeric/…?

AlexRevin commented 9 years ago

Exactly, + symbols

floere commented 9 years ago

@rdp For me, it would already be great if "native" objects would be supported.

rdp commented 9 years ago

Native means numeric in this case [I don't special store Strings yet, though that would be interesting...]

On Tue, Mar 24, 2015 at 4:34 AM, Florian R. Hanke notifications@github.com wrote:

@rdp https://github.com/rdp For me, it would already be great if "native" objects would be supported.

— Reply to this email directly or view it on GitHub https://github.com/rdp/google_hash/issues/21#issuecomment-85443561.