Is there a way to reuse a set of fields in a Vespa Schema?
If I had a set of fields that were structs and each struct had a set of identical fields is there a way to define the identical set once and reuse it in each struct through out the schema?
No there is not. Pretty much everything else supports inheritance but not structs. I can add it in a little while.
Related
I'm trying to come up with a way of storing the underlying structure of C++ classes in a database, and trying to determine what the best type of database would be/how to lay out information in that database.
C++ classes by themselves as code would be parsed into an AST, which would suggest a tree as a possibile data structure, which would fit well into a graph database. However, I don't think the data could be stored purely as a tree, once you consider that pointers could create a loop. The thought then would be a graph. Being someone primarily familiar with relational databases, I'm not sure what the plausibility of that is. The primary pieces of data that would be needed for a class are:
Class name
Children nodes, including their type and offset within the struct
For children nodes that aren't a primitive type, they would have a relationship to the class. This by itself seems like it would fit well inside of a graph database. The main thing I'm having a hard time envisioning is how things like pointers or arrays would be stored. Would those just have different attributes on the edge between the two classes? Is there some other way of storing this data that I'm missing which would work better?
P.S: We are using Elastic 6.x
AS Elastic Search is upgraded few breaking changes are also popped out. We have some relational data which requires to be managed either nested or parent/child mode.
For Final decision I was wondering with following questions:
How many nested documents/array size I can save in one field
We have to manipulate the fields often so whats the recommendation if we use nested field type
What are the limitations of Parent/child if we use 4 types of relations
I believe, answers of the above questions can help me decide the field type, let me know if there is any other thing I should consider
Thanks in advance
How many nested documents/array size i can save in one field
By default, you can have a maximum of 50 nested fields defined per index. In each of those nested fields arrays, you may store any number of elements.
We have to manipulate the fields often so whats the recommendation if we use nested field type
That's where nested fields come short, as whenever a nested document changes, you either have to reindex the whole parent document or figure out via scripting which nested document to update, but it can quickly get quite convoluted.
What are the limitations of Parent/child if we use 4 types of relations
In ES 6.x onwards, you're limited to a single join field per index.
As it looks like, it doesn't seem like either nested fields nor parent/child would work well in your case... Maybe there's another possible design if you are willing to denormalize a little bit more your data, but hard to say without getting more detailed information about your preceise use case.
Choosing Parent/Child vs Nested Document
I am looking to build a graph database for a new site that I'm building and came across neo4j.
Although it is a viable option, I don't like the idea of creating the labels and relationships on the fly. Instead I only want to define the labels and relationships before hand so my database can have a bit more stability to it.
Pretty much like a RDBMS where we define the tables and properties first but instead I want to define the labels and relationships and their properties first.
OrientDB allows you to do that. Look at:
http://orientdb.com/docs/last/Tutorial-Using-schema-with-graphs.html
http://orientdb.com/docs/last/Graph-Schema.html
Titan allows you do that also.
http://s3.thinkaurelius.com/docs/titan/0.9.0-M2/schema.html
Of particular interest to the original post, in section 5.5: It is strongly encouraged to explicitly define all schema elements and to disable automatic schema creation by setting schema.default=none in the Titan graph configuration.
One thing you can do is define this befor me the devoloper entered this in graph format (like a template?) for example, what is the node, it's properties, the relation...etc
I read some where that noe4j or other nosql database is schemaless. so what is the schemaless? I would like to know more about it with use case.
You don't need to define a schema like you would have to do e.g. in mysq with a table. Instead, you can add properties and their value to each individual node (entry), as you like.
E.g: if you look at the address book in an android phone a person entry can have a multitude of properties - phone numbers, addresses, names. Some people have a lot of attributes, some have none.
Doing something like that with a schema (e.g. table structure) is really hard, and requires advance planning of what your fields are, and how you want to query them in the future.
Without a schema you can more or less play it by ear, and add things as needed.
What needs deciding though is what to add as property to a node, and what as a related node. E.g. is an address a node, or just a property of a person? (Most likely a seperate node, but it depends on your use case)
For me, the classic wisdom is to store enum values (OrderStatus, UserTypes, etc) as Lookup tables in your db. This lets me enforce data integrity in the database, preventing false or null values, etc.
However more and more, this feels like unnecessary duplication to me. Not only do I have to create tables for these values (or have an unwieldy central lookup table), but if I want to add a value, i have to remember to add it to 2 (or more, counting production, testing, live db's) and things can get out of sync easily.
Still I have a hard time letting go of lookup tables.
I know there are probably certain scenarios where one had an advantage over the other, but what are your general thoughts?
I've done both, but I now much prefer defining them as in classes in code.
New files cost nothing, and the benefits that you seek by having it in the database should be handled as business rules.
Also, I have an aversion to holding data in a database that really doesn't change. And it seems an enum fits this description. It doesn't make sense for me to have a States lookup table, but a States enum class makes sense to me.
If it has to be maintained I would leave them in a lookup table in the DB. Even if I think they won't need to be maintained I would still go towards a lookup table so that if I am wrong it's not a big deal.
EDIT:
I want to clarify that if the Enum is not part of the DB model then I leave it in code.
I put them in the database, but I really can't defend why I do that. It just "seems right". I guess I justify it by saying there's always a "right" version of what the enums can be by checking the database.
Schema dependencies should be stored in the database itself to ensure any changes to your architecture can be easily perform transparently to the app..
I prefer enums as it enforces early binding of values in code, so that exceptions aren't caused by missing values
It's also helpful if you can use code generation that can bring in the associations of the integer columns to an enumeration type, so that in business logic you only have to deal with easily memorable enumeration values.
Consider it a form of documentation.
If you've already documented the enum constants properly in the code that uses the dB, do you really need a duplicate set of documentation (to use and maintain)?