FAQ
I am working with an interface that points to a struct.
And I need to search for data within it, without converting it back to a
struct, without type assertion, since I will be using this find method for
many different structs.
* It is part of a separate database package of mine. I'll be releasing it
on bitbucket once I get everything working. I figure Go could use some more
databases.*
Anyway, I created this golang play <http://play.golang.org/p/PWnOs9K5L9>program too make it easier to understand what I mean.

http://play.golang.org/p/PWnOs9K5L9

How would I do this?

--

Search Discussions

  • Chris dollin at Sep 23, 2012 at 2:39 pm

    On 23 September 2012 15:07, RoboTamer wrote:
    I am working with an interface that points to a struct.
    And I need to search for data within it, without converting it back to a
    struct, without type assertion, since I will be using this find method for
    many different structs.
    It is part of a separate database package of mine. I'll be releasing it on
    bitbucket once I get everything working. I figure Go could use some more
    databases.
    Anyway, I created this golang play program too make it easier to understand
    what I mean.

    http://play.golang.org/p/PWnOs9K5L9

    How would I do this?
    Define find methods for Struct and implement them for things
    that you want to search for.

    Chris

    (Interfaces dont' "point to" the values they contain, even if their
    implementation uses pointers.)

    --
    Chris "allusive" Dollin

    --
  • RoboTamer at Sep 23, 2012 at 4:28 pm

    Define find methods for Struct and implement them for things
    that you want to search for.
    --
    Chris "allusive" Dollin
    I created an new play paste <http://play.golang.org/p/9Ghg25Wr8T> based on
    your suggestion, or at leased my understanding of it.
    However, I am not quite sure if I understand this right, because if I do
    then more questions arise.
    Like what if I have to search for different types like uint or float?
    Sometimes it could be that the key is int other times the value may be a
    float.
    Do I have to convert everything to []byte back and forth?

    type Struct interface {
    Find(string, string) Struct
    }


    And there is no easier way to do this?



    --
  • Rémy Oudompheng at Sep 23, 2012 at 4:34 pm

    On 2012/9/23 RoboTamer wrote:
    I created an new play paste based on your suggestion, or at leased my
    understanding of it.
    However, I am not quite sure if I understand this right, because if I do
    then more questions arise.
    Like what if I have to search for different types like uint or float?
    Sometimes it could be that the key is int other times the value may be a
    float.
    Do I have to convert everything to []byte back and forth?

    type Struct interface {
    Find(string, string) Struct
    }


    And there is no easier way to do this?
    No. Reflection may give you a uniform way of doing but it will be very
    slow. You'd rather have all your items be of the same type, or have a
    common interface. Having a Find method on all types is a way to have a
    common interface.

    Rémy.

    --
  • RoboTamer at Sep 23, 2012 at 5:32 pm


    No. Reflection may give you a uniform way of doing but it will be very
    slow. You'd rather have all your items be of the same type, or have a
    common interface. Having a Find method on all types is a way to have a
    common interface.

    Rémy.
    I can't have multiple Structs (interfaces) Rémy, because I use the Struct
    interface to inject data in to the actual database.
    I can't expect users to make Find methods for every possible combination of
    types either that would be just ridiculous.
    So that leaves me with reflection, I guess.
    I have read the Laws of reflection<http://golang.org/doc/articles/laws_of_reflection.html?h=Reflection> but
    I am not sure how I would apply this here.
    Do you have any pointers?

    --
  • Jorelli at Sep 23, 2012 at 7:08 pm
    It appears the problem you have this is:

    given a collection of mixed type
    find the first item in that collection that matches some arbitrary
    search term

    Then you have two types: an interface type that defines something that can
    compare itself against some search term:

    type Matcher interface {
    Match(interface{}) bool
    }

    And a type to define the collection of these things:

    type Haystack []Matcher

    or something to that effect.

    http://play.golang.org/p/Bg7PrF5m53




    An object of interface{} type is not of any type; it is of interface{} type.



    what is it that you're actually trying to do? That is, the problem you're
    trying to solve, not the implementation you're trying to code.


    On Sunday, September 23, 2012 1:25:35 PM UTC-4, RoboTamer wrote:

    No. Reflection may give you a uniform way of doing but it will be very
    slow. You'd rather have all your items be of the same type, or have a
    common interface. Having a Find method on all types is a way to have a
    common interface.

    Rémy.
    I can't have multiple Structs (interfaces) Rémy, because I use the Struct
    interface to inject data in to the actual database.
    I can't expect users to make Find methods for every possible combination
    of types either that would be just ridiculous.
    So that leaves me with reflection, I guess.
    I have read the Laws of reflection<http://golang.org/doc/articles/laws_of_reflection.html?h=Reflection> but
    I am not sure how I would apply this here.
    Do you have any pointers?
    --
  • RoboTamer at Sep 23, 2012 at 10:58 pm
    Sorry if I wasn't clear about the purpose.
    Although I wasn't quite ready, since the code still need major cleanup and
    better documentation, I have uploaded the code for you to bitbucket.
    https://bitbucket.org/gotamer/jgdb

    I am using a backend that supports stings as well as numbers as key as well
    as as values.
    The backend is json.

    I need the Struct interface to inject the users struct in to json, with
    (this is important) the key/id of each map.
    If you are inspecting my code, this implementation is in the List type
    database. (list.go)
    There are two types the other is Object type database.
    The major distinction between those backends is that one, the List type
    uses a single file as backend with each record placed in one line.
    Where as the object type keeps each record in a separate file. The object
    type is/will keep track of these records with an index file and
    also optionally with a strtree for fast in memory access.

    How the List type works:
    1) The user creates a struct to his/her needs
    2) The database inherits that struct via the *Struct Interface*
    3) The database converts that struct to include the map id using *
    jsonListStruct*
    4) jsonListStruct struct is used to Marshal the data in to a json file

    *At the moment I believe the json interface must be broken, since the
    Struct Interface has been modified*

    What else is planed so far:
    1) Create a cache system with a user defined limit that keeps the most
    asked for items in memory.
    2) Create git backup
    3) Distribute with git push and pull

    Disadvantage:
    Well I know that git will not be that fastest distribution system

    Advantage:
    1) All data is kept in plain text/json
    2) Backups are incremental, I can't think of anything better then git to
    make backups.
    3) Distributed system. without the need for the master and slave concept.
    4) Every node is independent
    5) Database can get very big, bigger then what the memory can hold, and we
    will read less active data with io.Reader and bufio

    Now what do think, how I / we (Yes man you got your self in to this) should
    do this?



    --
  • Rémy Oudompheng at Sep 23, 2012 at 11:13 pm

    On 2012/9/24 RoboTamer wrote:
    What else is planed so far:
    1) Create a cache system with a user defined limit that keeps the most asked
    for items in memory.
    2) Create git backup
    3) Distribute with git push and pull

    Disadvantage:
    Well I know that git will not be that fastest distribution system

    Advantage:
    1) All data is kept in plain text/json
    2) Backups are incremental, I can't think of anything better then git to
    make backups.
    3) Distributed system. without the need for the master and slave concept.
    4) Every node is independent
    5) Database can get very big, bigger then what the memory can hold, and we
    will read less active data with io.Reader and bufio
    To get a proper distributed system you need (among other things) a
    merge strategy for your git repositories. How would you solve
    conflicts?

    Rémy.

    --
  • RoboTamer at Sep 23, 2012 at 11:16 pm


    To get a proper distributed system you need (among other things) a
    merge strategy for your git repositories. How would you solve
    conflicts?

    Rémy.
    Simple, before every save/commit a node is going to pull the latest
    changes, and then save, commit and push the changes upstream.


    --
  • Rémy Oudompheng at Sep 23, 2012 at 11:21 pm

    On 2012/9/24 RoboTamer wrote:

    To get a proper distributed system you need (among other things) a
    merge strategy for your git repositories. How would you solve
    conflicts?

    Rémy.

    Simple, before every save/commit a node is going to pull the latest changes,
    and then save, commit and push the changes upstream.
    That still makes a race condition whenever someone pushed something
    between your pull and your push. And since you don't want a
    master/slave scheme, "upstream" has no meaning.

    Rémy.

    --
  • RoboTamer at Sep 23, 2012 at 11:31 pm

    On Sunday, September 23, 2012 4:21:06 PM UTC-7, Rémy Oudompheng wrote:
    On 2012/9/24 RoboTamer <grue...@gmail.com <javascript:>> wrote:

    To get a proper distributed system you need (among other things) a
    merge strategy for your git repositories. How would you solve
    conflicts?

    Rémy.

    Simple, before every save/commit a node is going to pull the latest changes,
    and then save, commit and push the changes upstream.
    That still makes a race condition whenever someone pushed something
    between your pull and your push. And since you don't want a
    master/slave scheme, "upstream" has no meaning.

    Rémy.
    Sorry for the wrong terminology, you know what I mean up to the repository.

    Git is very good about automatic conflict resolution anyway. For example in
    the list database type each record is going to have it's own line.
    There will be no updates only insert, and delete. Delete will be
    done periodically by locking the repository / informing each node that we
    are deleting.
    Meanwhile, which is only like a second or two the notes are going to keep
    new data either in memory or in a different branch. As soon as the lock is
    lifted they will pull save commit and push.

    if this gets out of hand, by a vary active system, I will implement
    a communication system between the nodes so that only one node at a time
    can pull, commit and push. Basically implementing a lock on the repo
    when a node pulls, until it is finished and has pushed the data up to the
    repo.

    --
  • RoboTamer at Sep 23, 2012 at 11:36 pm

    On Sunday, September 23, 2012 4:31:12 PM UTC-7, RoboTamer wrote:

    On Sunday, September 23, 2012 4:21:06 PM UTC-7, Rémy Oudompheng wrote:
    On 2012/9/24 RoboTamer wrote:

    To get a proper distributed system you need (among other things) a
    merge strategy for your git repositories. How would you solve
    conflicts?

    Rémy.

    Simple, before every save/commit a node is going to pull the latest changes,
    and then save, commit and push the changes upstream.
    That still makes a race condition whenever someone pushed something
    between your pull and your push. And since you don't want a
    master/slave scheme, "upstream" has no meaning.

    Rémy.
    Sorry for the wrong terminology, you know what I mean up to the repository.

    Git is very good about automatic conflict resolution anyway. For example
    in the list database type each record is going to have it's own line.
    There will be no updates only insert, and delete. Delete will be
    done periodically by locking the repository / informing each node that we
    are deleting.
    Meanwhile, which is only like a second or two the notes are going to keep
    new data either in memory or in a different branch. As soon as the lock is
    lifted they will pull save commit and push.

    if this gets out of hand, by a vary active system, I will implement
    a communication system between the nodes so that only one node at a time
    can pull, commit and push. Basically implementing a lock on the repo
    when a node pulls, until it is finished and has pushed the data up to the
    repo.
    I think this is all solvable, and as long as I only do inserts, git will
    take care of conflict resolution anyway.

    --
  • RoboTamer at Sep 24, 2012 at 12:14 am
    Thanks for the code.
    Now, I am trying to incorporate your code from
    http://play.golang.org/p/Bg7PrF5m53

    I will need to build this in to the Struct interface, and as long as I keep
    the Haystack struct as lower case, like so *haystack* it will not effect
    the jsonListStruct I think.

    What I am not clear about is, what is the 0,10 in make(Haystack,*0,10*) ?

    var (
    items = make(Haystack,0,10)
    )

    --
  • Peter S at Sep 24, 2012 at 12:57 am

    On Mon, Sep 24, 2012 at 9:14 AM, RoboTamer wrote:
    Thanks for the code.
    Now, I am trying to incorporate your code from http://play.golang.org/p/**
    Bg7PrF5m53 <http://play.golang.org/p/Bg7PrF5m53>

    I will need to build this in to the Struct interface, and as long as I
    keep the Haystack struct as lower case, like so *haystack* it will not
    effect the jsonListStruct I think.

    What I am not clear about is, what is the 0,10 in make(Haystack,*0,10*) ?

    var (
    items = make(Haystack,0,10)
    )

    From http://golang.org/ref/spec#Making_slices_maps_and_channels :
    Call Type T Result
    ...
    make(T, n, m) slice slice of type T with length n and capacity m
    ...



    --

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 23, '12 at 2:07p
activeSep 24, '12 at 12:57a
posts14
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase