This is similar to the question Rails Migration: indexes on a renamed table, only that I'm now using Elixir/Phoenix/Ecto.
I just renamed a table, but I just realized that, it seems the indices are still kept with their old names and are causing problems. Should I follow the procedures used for Rails 3, i.e. first drop the old indices before renaming the table, and then re-add the indices with create?
I just worked through the same scenario but couldn't find any examples online of what it actually looks like in an Ecto migration to drop and recreate the constraints and indexes in the renamed table. I eventually figured it out and thought I would share what I did here in the hope that it helps someone out in the future: https://gist.github.com/wosephjeber/42472d6522d03161d710d5adb3dc3534
I'm by no means an Ecto expert, so there may be a better way, but this worked for me. I'm on Ecto 3.0 for what it's worth.
I am using neo4j.rb as the ORM for a Rails app, talking to a simple neo4j schema. I have a bunch of Person nodes and each node has two fields name and bio.
My goal is to be able to (a) search for people using a fuzzy name search which is case insensitive; (b) be able to do a full text search of the bio.
I am very confused about how indexing/searching works in neo4j. Not sure I fully understand the difference between 'schema' and 'legacy' indexing, or how Lucene fits into all of this. Most importantly, I do not understand which features neo4j.rb actually supports.
Thanks in advance.
I'm one of the maintainers of the Neo4jrb project. Indexing is pretty confusing for everyone but I can break it down pretty easily for you.
The gem doesn't deal with legacy indexing at all. The "legacy" designation suggests to us that it's not going to be around forever and that coupled with the fact that it's a bit clunky to use led us to decide not to implement it. Everything in the gem uses labels and property indexes, which are all Lucene exact indexes under the hood.
When it comes to search, if you want case insensitive and/or full-text search, you can do that in Cypher and the gem but it's going to work outside of indexes and it may be sluggish. It all depends on your data. This shows you how to do regex with Cypher. In the gem, you can do it like this:
User.where(name: /?ob/)
# or
User.as(:u).where("u.name =~ '?ob`")
My personal suggestion is to use the Searchkick gem to provide these features. It uses Elasticsearch, which uses Lucene, which is what Neo4j is using anyway, so you'll get more control and the same performance as you would with legacy indexing. The downside is you have one more moving part of your setup, but I think it's worth it.
Hope this clears it up. I'm going to add an area to the wiki about it since it's a pretty common question. Post here, open an issue on Github, or shoot me an email if you want to talk more about it.
EDIT: I added this to the documentation.
I am using the official gems suite of elasticsearch elasticsearch-rails, I am having really hard time trying to index a parent/child relation, and I am not sure whether my problems are in the mapping or the indexing or the querying or in all of them !! so I wont post my code snippets.
Is there a full working example of the following:
Mapping of both the child and parent indices
Indexing/Updating/Deleting of both child and parent
Querying an advanced query, on both indices; meaning that I need to search on the parent index with 'has_child' query, also need to search on the child index with 'has_parent' query and filter.
I found a full example using 'Tire' gem, and I copied a lot of it but still no luck and can't find the equivilant methods in elasticsearch-rails gem, please help!
I found this test inside the gem, which has exactly what I needed and It works !
Posting it if someone has the same issue.
Long ago I have learned sql and within the last years of application development I realized I only rarely really play with a real sql console or sql commands at all, especially since I mainly work with rails applications for a while now.
But right now I am working on getting a few Microsoft certifications, so for that I did end up relearning sql from scratch. And by that so many things come to mind that - I have to admit - I have forgotten over all the years. Yes, from a developers view, sql is important, but somehow I didn't need much of it... like stored procedures, functions, triggers, etc...
While I already found a nice blog from Nasir about using Views in Rails,
I am still wondering if I can use
functions
stored procedures
triggers
in Rails.
Triggers: Of course I wouldn't need do define triggers within a rails application. I would create them directly on the database management console. I'd just have to remember the things that are 'automatically' done. I would like to use those for logging purposes or pre-calculations of quick-access-tables ...
Functions: They should be easy to use I would think. Is it possible to add them via the 'select'-method of ActiveRecord?
Stored Procedures: How would one use those from Rails, i mean they could be valuable if you have several complex queries with multiple joins and calculation-based dependencies. I wonder a) how to call one and b) how to receive the results
Well, if you have more insight to the inner workings of Rails in relation to sql and could point out if these native sql-elements are available for/from a Rails-application it would be lovely if you could point at some Howto's, Tutorials.
Another thing I am wondering about is the use of foreign keys. Rails doesn't use them explicitly on the sql-side... would it be useful/helpful to manually add them to the database relations? Or would they hinder Rails' data access?
Thanks for any response, I am eager to find out what I can do between Rails and Sql to combine them in a maybe more efficient way.
As you will have noticed, and mention yourself: rails does a good job of hiding much of the sql/implementation details.
Still, I believe it is very important to use your sql and database wisely.
Validations
Validations should be defined on your database as much as possible, not only in rails. You define it in Rails to give nice user-feedback if needed. But ultimately you do not know how data gets into the database: some operator can use sql, maybe other programs interface with the database, or more frequent: two rails processes can insert data nearly simultaneously.
Foreign keys
Should most definitely be defined on your database. For rails is not needed, it will write the queries correctly, but this will guard your database against wrong data. This will safeguard your data integrity. If someones deletes a record and another record is still pointing to that, your database will complain.
Indexes
This is even more easily overlooked: create indexes! On your primary key (automatically), on much searched on fields (like name), on foreign key fields !!
Complicated queries
As much as rails helps you when retrieving items, for some queries it is much more efficient to write the query yourself. While I will avoid it as long as possible, find_by_sql is a powerful tool.
And rails is extremely powerful/helpful in treating the result of a find_by_sql as a normal result.
Stored procedures, functions, ...
Normally you do not need them when using rails. But there are some very valid cases where they are very useful. For instance, I have created a geographic information system, where we used stored procedures to create various spatial objects. In rails you can directly execute sql using the
YourModel.connection.execute(' .. your sql here .. ')
So even execute stored procedures. It will not be for everyone, but there are some very valid reasons to move work to the database. For example if you have to perform an operation over a whole lot of tables or rows, it could be very efficient to call a stored procedure instead of retrieving all the data, changing the rows, and saving them back. It depends on your problem at hand.
Conclusion
I want to make absolutely clear that Rails nicely abstracts the database away, and for everyday use this is just great. You should define foreign keys, indexes and constraints on your database. For the more advanced stuff like functions, stored procedures, complicated queries: Rails does not stop you from doing anything complicated if needed. One should consider your database as a tool as much as Rails is. But remember:
Premature optimization is the root of all evil. --Donald Knuth
So the options are available, but only use them if it is really necessary.
First of all, I don't particularly share your sentiments with regards to the following completely
Yes, from a developers view, sql is important, but somehow I didn't
need much of it... like stored procedures, functions, triggers, etc...
SQL is important if you're developing all the time for extreme "scalability" — and do note I'm using the term here very loosely as Rails does scale if you know how to go about it, but with limits as stories such as Twitter's switch from Rails etc. are quite ubiquitous.
However, Rails isn't always about extreme performance. It is first and foremost about developer 'happiness', increased productivity, and reduced time-to-market. This is done quite well, especially in Rails 3.x+ with the high abstraction introduced and it is this very abstraction that ultimately has resulted in Rails being considered as slow, and by most standards it definitely is.
Do note, that I do not intend to cause any 'language' flame-wars here but this is my personal take on the purpose of Rails; I like to call a duck a duck myself (much like two of my favourite languages: python & ruby).
The simple answer to your questions though can be realised as follows:
Triggers: AR callbacks
Functions: AR Query DSL, i.e. .where('name = ?', :full_name)
Stored Procedure: tied into model business logic, typically based on AR callback.
Another thing I am wondering about is the use of foreign keys. Rails
doesn't use them explicitly on the sql-side... would it be
useful/helpful to manually add them to the database relations?
Au contraire mon ami! All AR relations require that the various foreign keys are included in whatever appropriate migrations one includes. It's a common misconception that 'Rails will walk your dog and clean after it as well'. Remember that AR queries are ultimately expressed on your backend solution, in this case an SQL one for the sake of this topic, in SQL (alternatives are SQlite/PostgreSQL etc...).
However*, rails does not make use of FK constraints because you can actually make an _id field point to a non-existant record; they aren't really foreign keys in the strictest sense.
Note: the * indicates that credit for this statement should go to my friend David Workman (workmad3) and revision to the last paragraph of the above.
I am developing a Rails app which should rely on existing database.
There are a couple of table names there which are the always plural words, like "Series".
Application is not working correctly with the models associated with them. How would you propose to deal with it - is there any solution without changing the naming?
Thanks in advance!
It sounds like you need to tell Rails that "Series" is uncountable - that is, that it shouldn't try inflecting it for singular/plural. To do this, add the line inflect.uncountable 'series' to your config/initializers/inflections.rb file.
Curiously, however, "series" appears to be uncountable by default; did you just pick it as an example out of a number of similar names?