What would be an good way of storing application options in a neo4j database?
I have few settings that I would like to persist for an application.
In an SQL database, I would create a table with 2 columns (name and value) (and perhaps a few more, but you get the idea).
In neo4j I'm thinking about a single node (with a 'Config' Label) and have an attribute for each setting I want to store.
Is this a recommended way of doing this? Feels kind of strange for a graph database, since this node will not have any relationship.
That is a perfectly fine way to do what you want.
Related
we have two databases in our project, one for primary and one for backup. Both of the databases have exactly same data.
we have used EF designer model to get SP's from db. we call any method by just using object.spName . This is working perfectly if we have only one db. But since we have multi db system i need to make sure that insertion operation works on both db and select queries can be run from primary only and backup will be used to get records only if primary is down.
What is the best approach to get this working, or how can i specify multiple db in same connection string
You don't want to do this on the application layer... You should look into database technologies like replication to perform this, or use native database backups and restore them on a schedule
Imagine an error occurs between the first and second, or someone does a manual query - your dbs will be out of sync.
I would like to disable my rails application's oracle database partitioning, but :
I don't know how to tell whether my app is using database partitioning
I don't know how to find the place my app use partitioning, since I didn't write most of the application's code myself
Can I just system search the code base for the keyword 'Partition' and look for any result that has the key word partition in raw SQL statement?
How should I go about this?
Thanks!
Update:
I have 2 answers below and they seem to understand my question differently
I am confused now as well. I want to disable the partition feature of my Oracle Database (https://www.oracle.com/technetwork/database/options/partitioning/overview/index.html), does that means I cannot use the 'partition by' keyword (Oracle "Partition By" Keyword) anymore?
Partitioning is done at the schema level declaratively. Usually, one would not expect the application code to directly need anything specific to use partitioning since it is done at the data definition level. You can connect to the schema owner account and check the data dictionary views USER_PART_TABLES for partitioned tables owned by the user and USER_PART_INDEXES for the indexes.
To create nodes in Neo4j with the Neo4j.rb gem, for an empty database, you'd first define the model class as seen in the examples here: http://neo4jrb.readthedocs.io/en/7.2.x/ActiveNode.html
Let's say you have a work project with an existing Neo4j database with an existing schema, nodes, & relationships. What would be the "Rubyist" way to generate models from the schema of an existing Neo4j database? The end goal would be to retrieve and edit existing the nodes and relationships using Neo4j.rb.
There was a discussion days ago in which I participated:
Rails Neo4j How to add new field in existing database
And the final conclusion was that you don't have to worry about this.
Nodes act as schemaless storages, and the getters for them doesn't work like ActiveRecord, that's why you don't even inherit from the module.
You can create a model for those nodes, include only the properties you want to handle in the class and work with them without having to worry about legacy properties or even schema.rb, because you are actually just pointing to the nodes based on their stored information, like ID, or existent properties.
I recommend you reading both the question and the answers and even the discussion in GitHub to get a better idea of the "problems" that handling legacy nodes, or maintaining them in time carries, and find a way to handle them that fit your project.
I have started a rails project on top of a legacy database. Standard practices required to use an ORM, like assigning ID field to each table, haven't been followed. So, I will not be creating all the models matching all the table. I need to run queries joining multiple tables using numerous conditions. I will mostly be using Model.find_by_sql or Model.connection.select_all methods. Where should I put these queries? Should I stash these in one of the models I have created that is involved in the query?
What's the standard practice for such a situation?
As much as possible, you still want to insulate the rest of your application from the details of the database by putting your queries and whatnot into the model layer. So yes, "stashing" in the right model object relevant to what you're trying to do seems like the right thing.
Are you allowed to change the schema of the database? If so, you may want to use migrations to slowly make your database look more like a standard ActiveRecord backing store.
You may also want to look into alternatives to ActiveRecord such as Sequel.
It is good idea to place the sql queries under sql folder under db. You need to create the sql folder.
I'm learning Rails, and the target of my experiments is to realize something similar to Zoho Creator, Flexlist or Mytaskhelper, i.e. an app where the user can create his own database schema and views. What's the best strategy to pursue this?
I saw something about the Entity-Attribute-Value (EAV) but I'm not sure whether it's the best strategy or if there is some support in Rails for it.
If there was any tutorial in Rails about a similar project it would be great.
Probably it's not the easiest star for learning a new language and framework, but it would be something I really plan to do since a long time.
Your best bet will be MongoDB. It is easy to learn (because the query language is JavaScript) and it provides a schema-less data store. I would create a document for each form that defines the structure of the form. Then, whenever a user submits the data, you can put the data into a generic structure and store it in a collection based on the name of the form. In MongoDB collections are like tables, but you can create them on the fly. You can also create indexes on the fly to speed searches.
The problem you are trying to solve is one of the primary use cases for document oriented databases which MongoDB is. There are several other document oriented databases out there, but in my opinion MongoDB has the best API at the moment.
Give the MongoDB Ruby tutorial a read and I am sure you will want to give it a try.
Do NOT use a relational database to do this. Creating tables on the fly will be miserable and is a security hazard, not just for your system, but for the data of your users as well. You can avoid creating tables on the fly by creating a complex schema that tracks the form structures and each field type would require its own table. Rails makes this less painful with polymorphic associations, but it definitely is not pretty.
I think it's not exactly what you want, but this http://github.com/LeonB/has_magic_columns_fork but apparently this does something similar and you may get some idea to get started.
Using a document store like mongodb or couchdb would be the best way forward, as they are schema-less.
It should be possible to generate database tables by sending DDL-statements directly to the server or by dynamical generating a migration. Then you can generate the corresponding ActiveRecord models using Class.new(ActiveRecord::Base) do ... end. In principle this should work, but it has to be done with some care. But this definitely no job for a beginner.
A second solution could be to use MongoMapper and MongoDB. My idea is to use a collection to store the rows of your table and since MongoDB is schema less you can simply add attributes.
Using EntryAttributeValue allows you to store any schema data in a set amount of tables, however the performance implications and maintenance issues this creates may very well not be worth it.
Alternately you could store your data in XML and generate an XML schema to validate against.
All "generic" solutions will have issues with foreign keys or other constraints, uless you do all of that validation in memory before storage.