Change naming strategy in Aqueduct ORM - dart

Is it possible to setup Aqueduct ORM to use underscored names for database columns (so if I have field "someField" in model class it will be stored as "some_field" in the database)? Or may be it is at least possible to override column name by some annotation? I have legacy database schema with underscored names and I cannot change it).

This is not supported yet, as of May 2020. Please upvote the associated Github issue.

Related

How do I reverse engineer a PostgreSQL 9.6.6 database for Rails?

I have a database in PostgreSQL 9.6.6 already defined, how do I reverse engineer that into Ruby on Rails?
[Please don't flame me if this has already been asked, I couldn't find an answer when I searched.]
Thank you.
Understood, i read your comment. But the thing is, Model with relations and attributes in rails provide by Active Record, in fact you cant export all stuff from random database.
You need to create migrations/models with Active Record Associations and object attributes, and after that Seed new database.
Somebody correct me if I'm wrong:
It would seem to me that since rails determines what columns are in a table by actually looking at the table definition in the database, that we (I) don't have to "reverse engineer" the database.
If rails is interrogating the database for the definitions, then the only thing we would have to do is define the relationships in the ORM classes and that we don't have to create migrations.

Create Ruby on Rails project from an sql file

I have a previously separately managed sql file containing rather simple but large database. Would there be a way to import this sql file and generate ruby code as models using this data as a starting point for my future development?
Thank you for your help!
Yes!
It will take some work!
And you'll need to post a WHOLE HELL OF A LOT more detail to get more than that. ;-)
Taking a stab:
Rails can use legacy databases with a lot of effort manually specifying foreign key columns, table names, etc. It can be done. My suggestion, though, would be to convert the data in-place in whatever database you have by using a lot of ALTER TABLE RENAME... work and same for columns to make the old DB conform to Rails' convetions (primary key == 'id', table name is plural underscore'd version of model name, all that) before doing the import, and then you can just use plain vanilla ActiveRecord and all will be easy.

Rails : Datatypes for ActiveModel- with PostgreSQL

I was using this command to create a model class "Listing". However, I was interested in knowing the relationship between the datatypes of the model and the datatypes of the underlying database. In this case, it is PostgreSQL. So when I type this command:
rails generate scaffold Listing name:string
I want to know what are the possible values I can use to describe the types. What is that dependent on? The underlying database? If so then what happens if the underlying database changes later? Also, where can I get a list of the types I can use here and their capacity with an underlying db of PostgreSQL?
That command actually creates migrations for creating tables, etc, on the DB, so that's where you should check the types supported.
I would copy/paste here but I think there is no need to.
http://guides.rubyonrails.org/migrations.html#supported-types
UPDATE
The link to the docs does not contain the information anymore. Go to this question Rails 4: List of available datatypes for the full list

What is the common way to define models in Rails application?

All of the tutorials I've seen so far for RoR have shown me generating models like:
rails generate User name:string placeofbirth:string
This generates a class for the model, and only actually references an attribute if I apply a validation of some kind.
So my question is, how do I use a 'code' first approach when creating my models. Or is it the rails way to just right down on paper the attributes you want, run the generate command with each attribute you want and it's type, then run the rake db:migrate command?
I'd love some more proven patterns on this subject because so far the way I've seen seems too empty.
Yes, this is the rails way- migration comes first and generates the code and the database- and the model class inspects the database to see what fields are there and make accessible via methods.
You can do gem install annotate_models if you want to get some comments in your model class with the attribute names and types.
See here for an example: https://github.com/ctran/annotate_models
Rails uses an active record pattern for models which basically means that a model object will automatically map each DB column to an attribute so you don't have to specify all attributes in the model. It's a feature, but I agree that it might not be perfect for everyone. If you're using Rails 3 it should be easy to use another ORM of your choice if ActiveRecord's approach doesn't suit you. Here are some alternative ORMs that you could use.
Usually when you are developing some database backed web application, you know the database design(name of the tables, name of the columns in those tables and associations between different tables) beforehand.
Rails, as mentioned by maarons in his answer, uses Active Record pattern. Your models are classes that represent a table in your database, an instance of your model class a row in that table and different attributes of an object represent values under different columns in the same table.
When you create a model, usually, you are creating a class that represents one of the tables in your database. And while you are creating a model, you are also going to create a table in your database. That means knowing the name of the table and columns within that table.
So to answer your question, you must know all the columns, required for the time being, that will be in your tables. And hence available as attribute methods for your model objects. You specify these columns to added in the table in the migration generated by rails generator while generating this model. This is what usually everyone does.
You can take a code first approach by creating a class, without running the rails model generator,under app/models/ but not inheriting it from ActiveRecord::Base. As you move forward in your development, you can generate migrations by $ rails generate migration MigrationName and creating table and adding columns using [add_column][2]to that table as required. Once you have created a table for this model, you will have to inherit that model from ActiveRecord::Base so that you can get all the Rails magic in your application.

How do define the schema that a rails model is set to?

For instance, when I generate an Event model, the table automatically sets to the public schema. How do I specify it to get set to a different schema?
Furthermore, how do you alter the schema of an existing table? Perhaps move it to a different schema?
Thank you!
Disclaimer: I don't know rails, so I'm going to give very postgresql-oriented answers here. For the first part of your question, there is quite possibly a much better way to do this, by making rails specify the schema when creating tables.
In PostgreSQL, tables are searched for in schemas according to the search_path setting. This is set by default to "$user",public. Tables are created in the first schema found in the search path that exists. So if you connect as "my_user", it will try to create tables in "my_user", and fall back to creating them in "public" if "my_user" doesn't exist.
So one approach is to update the "search_path" setting used for the user you connect to the database to make schema changes. For example you can say ALTER USER my_user SET search_path = my_app, public. If you then create a "my_app" schema then subsequent CREATE TABLE foo(...) commands executed by "my_user" will put the new table into "my_app".
You can change the schema of a table using ALTER TABLE foo SET SCHEMA my_app.
Create a migration to generate your new schema. ActiveRecord can't update you schema to you it's the pattern system. You can try sequel or DataMapper if you want update you schema from your code.

Resources