Refactor child classes

[ahincks]

A huge commit that refactors things to avoid repeating lots of similar code in the child classes of Vertex. The API to the external user should be basically the same as before, with the main exception being that you need to explicitly set the attributes when initialising a Vertex child instance: e.g., p.ComponentType(name="mytype", comments="sldkfj") rather than p.ComponentType("mytype", "sldkfj").

I think this PR should be merged now, but later I plan on some more modifications:

• The Flag class has not yet been refactored. That's because it currently accepts TimeStamp objects and that isn't possible to handle through the new _vertex_attrs system that the refactoring uses.
• There are some class methods that can be can be refactored as well, like get_list(), get_count(), __repr__(), __str__().
• There should be a Component.get_properties() method analogous to Compenent.get_connections(), instead of the mismash of overcustomised methods for getting lists of connectins.
• Reduce the number of overly specific, bespoke exceptions; use built-in exceptions whenever it makes sense.

[ahincks]

All of those attributes are included in the parent, Vertex, class, so all the children inherit them and they shouldn't be included as _VertexAttr instances.

But you're right that as_dict() should include these. Let me make the fix.

[ahincks]

OK, made the fix. I've tested it quickly on the web interface and seems to work.

[jfitzgerald1126]

I see, that makes more sense. However, I also noticed that when I checked out the branch and cleared the database, any new components added didn't represent lists with multiple values properly. For example, Property vertices would only store the last value in the values list if multiple values were defined. I'm not sure what caused this issue because the issue resolved when I restored the old database I had.

[ahincks]

I'm not sure I follow completely. Is it simply that when you are creating a Property not all the values are being stored? I just checked and I am able to store multiple values. Maybe you could create a reproducible example of the problem you're having?

[jfitzgerald1126]

Yes, I cleared the database because the components I had caused key errors on either init or from_db because they were missing the uid_added property. With the fresh database, any new properties I added only stored the last property in a list, for example [1, 2, 3] would just be stored as [3], and cause errors. I even created a fresh instance from main and a new JanusGraph install, but had the same issue. I was only able to resolve the property issue by restoring the database I had previously.

I'm not sure what caused this issue but I can see if I can reproduce it.

[ahincks]

OK. Did you try running padloper/scripts/tests.py? One thing it does is create properties and add them to components, and it works for me with multiple values in the components. But if you have an example where things break obviously I want to know!

[jfitzgerald1126]

Resetting the database fixed the previous issue, but I'm still not sure what caused it. Everything seems to be working except n_values is being returned as a string from queries to the DB in from_db, get_list, etc. This is causing type errors on __init__ calls.

[ahincks]

I sent this to @jfitzgerald1126 in Slack but then realised I should probably have put it here, so let me cut and paste and lightly edit:

• Hi John: so I spent a bit of time figuring out defining the vertex/edge properties. It turns out that the index_setup.txt file already included a command to make values into a list.
  • (This is why you found this bug and I didn't!)
• However, I have edited it now to explicitly define all property types and edge label in index_setup.txt. (This is in the current branch of this PR.)
• I also discovered that it is recommended to disallow automatic creation of property types, which is what was at the root of your weird bug where lists were behaving inconsistently. You can do this by setting schema.default=none in the config (by default, conf/janusgraph-cql-es.properties).
• In this PR branch, I have edited README.md to give explicit instructions for this, in ‘Setting Up JanusGraph’. If you do a fresh install using these instructions it will hopefully work: at least, I was able to run padloper/scripts/tests.py and it worked; the web interface also seemed to work though I didn't test everything systematically.
• So maybe you can verify that this works?
• I think the only issue you might have is if you go ahead and set schema.default=none, and then you have vertex properties that you have added in your branches that aren't defined in index_setup.txt, JanusGraph will throw an exception when you try and set them. But you can see in index_setup.txt how to define them.
• Finally, as I was doing this, I realised that Anatoly for some reason uses labels to distinguish different types of edges (e.g., rel_connection, rel_proprety, etc.), but to distinguish different types of vertex, he uses a property called category rather than a vertex label. I'm not sure why he opted to do it this way. For edges, labels are required, but for vertices, they are optional, so it works, and is probably just as efficient once you have indices, but it is a bit odd.
  • At this stage, it's probably not worth changing since Mohan will be deploying soon but if we can think of a really important reason …