G-star logo

Summary

In the beginning . . . Current Research and Development Usage

Questions, Answers, and TODOs

  • Summer 2016
    • Implement debug mode where we cause G* to output storage manager details, CGI details, checkpoints, etc.
    • Stop G* from creating duplicate vertices and edges.
    • Implement more graph queries: shortest path, connected components, Page Rank, rising stars across multiple graphs, two-hop influence.
  • Summer 2015
    • Continue working on our papers. See the G* Reports Git repository.
    • Output whatever we're printing to the server console (query steps, checkpoints, etc.) to the log.
    • Revisit the code for retrieving edges and consider returning ALL of them instead of just the half of them that we need to draw the graph.
    • Develop facility to detect the vertices and edges managed by a specific worker.
    • Develop facility to remove a vertex and its edges from a specific worker.
    • Develop facility to add a vertex and its edges to a specific worker.
    • I wonder if we can add a 'label' attribute to graphs. Something like "create graph [int] [string]" where both are optional. If we did this, then "set active graph" would probably have to work with labels too, though one can look up the target graph ID with "get graphs" so it's not critical at first.
    • We can display some real-time master and worker configuration data (their IP addresses). We need to add their vertex and edge counts as well as load data.
  • Spring 2015 - More than 8,000 lines of code spread over 520 GitHub commits so far.
    • Add attributes to vertices
    • We are not getting meaningful error messages back from the server when there's a database error. I think it may have to do with quotes " in the body of the error message. Somebody please fix this.
    • Force intermittent checkpoints in G* to cause the index (CGI) flush to disk. This may help prevent restart errors caused by people (Alan!) forgetting to shut down first. This may also help prevent the Heisenbugs we were seeing that caused graphs to mysteriously add duplicate vertices to themselves.
    • Graph cloning works.
    • We think we have determined the best practices for managing database connections and queries. Streamline all PostgreSQL access with this (logging and SELECT commands).
    • One might wonder whether or not we should integrate something phpPgAdmin in an iFrame somewhere to enable full relational database tooling. One might further wonder whether or not that should that be a separate tool, perhaps linked from Alan's G* site? One can keep wondering.
    • We now accept "new graph" (no param) in the Graph Editor and Graph Console. We needed a thread-safe (synchronized) "getNextGraphId" routine for G* to use internally in order to prevent race conditions. We also needed to return the newly created graph id to the user. Here's how it goes:
      1. start critical section (in Master)
      2. gid = get the next available graph ID
      3. end critical section
      4. make a new graph with with id gid.
      5. set active graph gid (this notifies the user too)
    • We can handle queries returning columns with the same name but from different tables.
    • Integrate PostgreSQL with SELECT commands from Studio. Results will be displayed in the Data panel.
    • Track G* server liveness (_stillAlive?), check server calls accordingly, and handle "Are you still there?" requests.
  • Fall 2014
    • We started thinking about writing a paper or two. The G* Reports Git repository was added and we began collecting"diary" entries. Alan has talked about extending the BD3 paper (but that's about it so far).
    • One may wonder: how ever did we get our Java code talk to our PostgreSQL database? Read about it from PGCon 2014.
    • We wondered: Should APIserver be separate from APIrest? Though there are pros and cons, we decided to keep them the same, using NanoHTTPD (see below).
    • We wondered who would bring us cookies since Mike could not be counted on to do it. Shane did it. Then Thomas brought us Candy Corn. What's next? As it turns out, I really like Swedish Fish. (Who knew?) Then Mike came through with the cookies! Thanks, Mike.
    • We invented an API. See the G* REST API Server home screen for details.
    • We worried about what enhancements needed to be made inside G* to implement the API once we figured out what it looks like. As it turns out, a few. Alan and Melissa worked on it. It's good, but will be continuously revisited.
    • What about logging? Cassie and Shane worked on it. Text and database logging (PostgreSQL on Amazon RDS) are working, more or less.