Modeling db to store multilanguage content, geolocations data and using Foxx with existing collections?

[Salines]

I need to create an application that has two user groups A and B.

Group "A" of users, can create multilingual posts, where "p" collection includes uuid key and metadata and "t" Collection stores content in different languages and has a fulltext index.

- Is this the correct way to store multilingual content in arangodb?

Group "B" of users, can create multiple collections, where "l" collection has a geo index on the lat and lon values, plus other meta data.

As you can see in the attached picture, the two user groups have one common connection, this can be a collection "v" or edges with additional meta data?

My application needs to find the nearest location "l+B", and localized content (language code + keywords) "p+t+A" and  together with the "v" metadata return as JSON data.

Can anyone give me an example of how it will look AQL queries?

Last question, how to use FOXX with existing collections?

Thanks.

[Wilfried Gösgens]

Hi Salines,

In general AQL queries always return you json documents. You may want to only return sub-parts of documents to reduce the size of your result set for better performance:

  FOR example IN [  {first: true, a: [{b:'c'},   {d:'e'}]}, {second: true, a: [{f:'g'}, {h:'i'}]}   ] RETURN example.a[1]

will result in:
[
  {d:'e'},
  {h: 'i'}
]

instead of returning you the full two documents specified as the list (to replace a collection for better overwiew)

Regarding The queries,
you can use two different solutions to mix two data sources in AQL:

 - Joins   -> https://docs.arangodb.com/AqlExamples/Join.html (n:n relations)
 - Graph traversals -> https://docs.arangodb.com/Aql/GraphTraversals.html (n:m relations)

We also have an example howto link a graph with geo index queries:
https://docs.arangodb.com/AqlExamples/CombiningGraphTraversals.html

You would start query with the geo index, filter for certain stuff, and maybe start a graph query from the result set, etc.

You could also join a sub query with the results of a graph traversal. It depends a bit whats able to best limit the result set.

The fulltext index works similar to the geo index - query it, filter for your user, and then maybe join in other stuff to your result.


    FOR user IN WITHIN(usersCollection, @lat, @long, @radius) FOR v, e IN 1..1 OUTBOUND user usersToItemsEdgeCollection FILTER e.someProperty == true RETURN {startUser: user, related: v, mapTo: e}

As above, you may choose in the RETURN statement whether only sub-parts of the documents are returned.

In general, https://docs.arangodb.com/Graphs/index.html tries to give some decision help when to choose graphs with edge traversals or joins or when and how to mix them.

Regarding foxx, its seen as good practice to have the setup ensure the environment is sane (validate the collections it uses exist and create them in doubt); However you can do regular AQL queries.

Cheers,
Willi

[Alan Plum]

Hi Salines,

you can use Foxx with existing collections by passing the collection names directly to `db._collection` (from `require('org/arangodb').db`) instead of using `applicationContext.collection`. The `applicationContext.collection` method uses the same thing under the hood, it just runs the name through `applicationContext.collectionName` first to generate a prefix based on the service's mount path. As Willi pointed out you might still want to make sure the collections actually exist in your setup script as usual, though.

As for the language data: the approach you describe seems the most straightforward solution to me as well. The right choice likely depends on your requirements and what tradeoffs you are willing to make (there are always tradeoffs).

Alternative approaches generally involve having the language data inside the metadata document, either as "embedded documents" (i.e. just copy-paste the entire sub-documents as an array or an object mapping the language or translation ID to the sub-document) or inlined so each language aware string is an object (again with an array or a map). This avoids the extra join (which is negligible in ArangoDB compared to similar databases) but makes the structure difficult to index and unwieldy (especially when dealing with many different languages or multiple translations per language).

Cheers,

Alan

[Salines]

Thank you for your answers. This database is what I need for my startup, later I might add some more questions.

Best regards