我们已经知道了如何为航线图创建模式，索引，我们可以使用和廷克图处理一样的基本的步骤加载它到杰森图中。注意在从XML文件加载了图之后，我们需要调用commit来完成事务。
Now that we know how to create a schema and an index for the air-routes graph we can use the
same basic steps to load it into a JanusGraph instance that we used with TinkerGraph. Note that
after loading the graph from the XML file we then call commit to finalize the transaction.
注意在加载航线图前我们没有定义模式，杰森图仍会创建顶点、边和属性但是使用的是默认的类型的配置。稍后我们也将看到为航线图创建索引。强烈建议在加载数据之前和定义模式一样创建索引，但是让我们在讨论怎么做之前了解更多的东西。
Note that had we not defined a schema before loading the air-routes graph that JanusGraph would
have still created the vertices, edges and properties but using default types and settings. A bit later
we will look at creating an index for the air-routes graph as well. It is strongly recommended to
create the index as well as the schema before loading the data but lets examine a few more things
before we discuss how to do that.
与廷克图不同，杰森图不会，默认的，保证遵照我们提供的顶点和边的ID值。相反当顶点和边加入到图中时，它会创建它自己的。您可能已经从本书前边或者从航线图文件中（如果您刚好看到那）注意到，在GraphML文件中AUS的ID是3.然而如果已将航线图加载到杰森图中，如查我们查询AUS顶点的ID，我们会发现它不再是3了。有一个配置可以更改从而确保杰森图遵照我们提供的ID，但是不推荐这样做，因为这将会禁掉杰森图一些有用的功能。如果您对些感兴趣，您可以参阅杰森图的文档。
Unlike TinkerGraph, JanusGraph does not, by default, guarantee to respect user provided vertex
and edge ID values. Instead it creates its own ID values as vertices and edges are added to the
graph. You may have noticed from earlier in the book or from the air-routes.graphml file if you
happened to look in there, that the ID provided for Austin in the GraphML markup is 3. However,
having loaded air-routes into JanusGraph if we query the ID for the Austin vertex we can see that it
is no longer 3. There is a setting that can be changed to force JanusGraph to honor user provided ID
values but it is not recommended this be used as it will disable some other useful JanusGraph
features. If you are interested in learning more about this option this please refer to the JanusGraph
documentation.
让图系统分配它自己的ID值这是不一个大问题，因为我们可以查询图得到ID值，但是记得在进行图的处理时，您要消除依赖任何用户提供的ID的习惯。
Having the graph system allocate its own ID values is not a big problem as we can always query the
graph to get the ID but it is a reminder that you should not get into the habit of relying on any user
provided ID values as you work with graphs.
和前边讨论的一样，如果需要，为了以后的使用，我们也可在变量中存储重要的ID值。
If necessary, as discussed earlier, we can always store important ID values in a variable for later
use.
注意属性值没必要按您需要的顺序返回。可以从上面的例子中看到。我们的value步骤是city在前，但是结果事实上是描述desc属性的值先返回了。小精灵没有保证返回的记录按您需要的顺序返回。它们是按照它们在遍历中被找到的顺序返回的。您不能依赖您的查询中各项的顺序来建立依赖关系。如果您需要特定的顺序，您应该进行排序或者操作查询的返回结果来满足您的需要。
Note that property values are not necessarily returned in the order you requested. That can be seen
by looking at the example above. Our values step had city first but in fact the desc properties value
was returned first. Gremlin makes no guarantees that items will be returned in the specific order
you requested. They are returned in the order in which they are found during a traversal. You
should not build in dependencies to your queries on the order things are returned in. If you need a
specific ordering you should sort or otherwise manipulate the returned results of a query to match
your needs.
浙公网安备 33010602011771号