I am looking to model some common vertex types like email address, phone number, postal address that would exist off of different vertexes. For example, a “person” would have zero or more email addresses as would a company. I want to reuse the email vertex and use the same edge name “hasEmailAddress” or something from both person and company for ease of use and consistency in naming.
When I tried to do that in designer I get an error about needing unique edge names in a graph.
Is there any way to do what I’m trying to accomplish?
Sort of “never mind” I think. I did find that from the gsql console I could create the edges I needed to create like
create undirected edge hasPhoneNumber (from UniversalPerson, TO phoneNumber | from UniversalOrganization, to phoneNumber)
I don’t see a way to do that from GraphStudio though. Is there a way to do that visually?
Not yet, no. That will no doubt be on the list of things TODO.
OK, thanks … would be a good feature to add.
At the moment, if I add a new Vertex and want to connect an edge there to one of my common vertex items (to email for example), would I need to run an alter command of some form from the gsql console?
I don’t think so, no. Historically, schema changes (in the developer edition) resulted in losing your data but this has been relaxed lately.
Generally, in graph studio, if you do this, it will, as you’ve already discovered, be a new edge type.
Yep, I understand that this can’t be done from Graph Studio. My related question was about doing this from gsql, is the right approach to create a schema change job with an “add … edge …” command or is there some easier way if I’ve published the schema but not created a graph based on the schema yet?
Schema change jobs are good for when you have existing data. Otherwise, simply recreating the graph is usually what we do.
That assumes, of course, that you have the schema already in the script.
If you haven’t, then getting that out of gsql requires a bit of editing after a ‘gsql ls’ command or similar.That does require some basic familiarity with the unix command line, but is not too difficult.
Does that match your situation, or am I missing things?
For initial tinkering around and learning dropping and recreating the schema then reloading data is a reasonable workaround although I’m not a UNIX person really so it may take some work to get things in good enough shape to work for me … I was kind of expecting that the schema export would produce a more useful output in the form of some schema script that I could then capture/edit and reload but that isn’t the case.
For any real deployment for real use cases, obviously evolving the schemas by dropping everything isn’t viable.
So, as you say, in production, you’d use schema change jobs or via Graph Studio (which does the same thing). This is just a development option.
I’ve been meaning to write a mini-export script. I’ll push it up my priority list. I’ve been flattened with work recently, but may have some time over the next few days. @Jon_Herke did we get a script done recently? I know it was something we discussed.
Amen on the schema export. Believe me when I say we have been quite vocal about this 
The engineering team juts got v3 out the door so there is a good chance we can get this prioritised with reference to people like yourself on here!
If you do still get blocked, let us know. We’ll help out as much as we can.
Thanks for the reply … I’m not blocked at this point but thanks for the offer. I’m mostly in “learning” mode that will feed into some corporate wide efforts so mostly poking at the edges right now.
Ramki, the author of this blog did write a script to do just this. The logic of that process is defined in the tail part of his blog: https://medium.com/@ramapitchala/migrating-to-giraffle-for-tigergraph-remote-tigergraph-part-1-82b55a5bc219 I’ll check to see if he can open source this capability.
The engineering team juts got v3 out the door so there is a good chance we can get this prioritised with reference to people like yourself on here!