I'm working with a grails project which uses a large 3rd party database with numerous tables and numerous fields in each table. We have taken the approach of adding these fields to our domain classes manually on an as-needed basis.
I'm at a point where I'd like systematic access to all of the fields and I'm wondering if there's a way to do this without adding them to my domain class. For example, if I know the column name, I'd like to know the datatype in the database (i.e., whether it's a string, double, int, bool, date).
I don't need programmatic access to the fields because I can interact with these tables using a REST api provided by the 3rd party vendor. I'd just like to know if I can determine what datatype they're expecting.
I found that grails has a reverse engineering plugin, but I'm not sure that's what I want because I don't want to create a domain class, I just want something like:
// this is what I work for fields I've added to the domain class
Type works = MyDomainClass.getDeclaredField("declaredFieldName").genericType
// is there a way to do this without adding it to the domain class?
Type needed = someAPI(MyDomainClass,"unDeclaredFieldName")
Check out the hibernate tools that the reverse engineering plugin is using. Specifically, it creates a DatabaseCollector:
DatabaseCollector readDatabaseSchema(String catalog, String schema) {
catalog = catalog ?: settings.defaultCatalogName
schema = schema ?: settings.defaultSchemaName
JDBCReader reader = JDBCReaderFactory.newJDBCReader(cfg.properties, settings,revengStrategy, cfg.serviceRegistry)
DatabaseCollector dbs = new MappingsDatabaseCollector(mappings, reader.metaDataDialect)
reader.readDatabaseSchema dbs, catalog, schema, new ReverseEngineerProgressListener()
dbs
}
I think you can just use straight SQL for instance
SELECT DATA_TYPE FROM all_tab_columns WHERE table_name = 'TABLE NAME' AND column_name = 'COLUMN NAME'
And you can call SQL directly from Groovy sql http://docs.groovy-lang.org/latest/html/api/groovy/sql/Sql.html
How do I control the order of the Database Columns in my Domain Classes?
I use my domain objects to create the database tables but I would like the fields in the database to be in a certain order.
Is there a way I can control this order in my domain classes.
You can control the creation of the database schema by using the Database migration plugin. You can read more about how to use this plugin it in the documentation.
We have a table (AttendanceType) in our database which have many fields with multiple options. this multiple options are defined in single table. So, instead of creating separate Option table for each option we have single table (Option_Data) with key to identify each option type (Record).
Example : AttendanceType table has following fields
ID
Description
Category (Payroll / Accrual)
Type (Hours / Days)
Mode (Work hours / Overtime / ExtraHours)
Operation (Add / Minus)
These fields have options (data as shown above in brackets) which comes from Option_data table. We have created separate views from this Option_data table example: vwOption_Attendance_Mode, vwOption_Attendance_Operation etc.
Now, how we can link this view in breeze so the reference data come automatically.
We are using EF6, SqlServer, Asp.Net WebApi. When the table relationship is defined in SQL Server Breeze works perfectly and manages the relational data. In this case we cannot define relationship in SQL Server between Table and Views.
How we can code it so Breeze can manage the relational / reference data for us? If you require further clarification please let me know.
Edit # Jay Traband : Let say a single table (ie: AttendanceType) has fields which get reference/lookup data for its field from Views. How in breeze we can relate them (table with views), as in SQL Server we cannot.
My reference points is when Tables are related breeze does excellent job. I want to achieve same with table and views.
Breeze gets its metadata (including the relationships between entities) from EF. You'll need to tell EF about the relationship between the tables and views, even if there is no such relationship defined in SQL Server. This SO post provides some clues, and this blog post gives some related information about creating relationships in the designer.
I am developing MVC application and using razor syntax. I have used model first method.
I have two entities, Customer and Lead. Lead is inherited from Customer.
When IsActive property is true then Customer treated as a Lead, otherwise it will be a customer.
Please check edmx file image.
Now, In regular entities we just deal with single entity and single table.
In this case how can I handle , Save and Load process. beacuse I have to store and load the record from 2 tables of DB.
Is Regular Index View will work here ?
When using inheritance in the Entity Framework you will have a single DbSet on your DbContext that exposes your hierarchy. In your database you have several options for configuring your table structure. For example you can use:
Table per Hierarchy
Table per Type
Table per Concrete type
(See this blog for a nice explanation: Inheritance in the Entity Framework.
In your queries however, you don't have to think about this. Your queries will have the following structure:
var leads = from l in dbcontext.Leads.OfType<Customer>()
select l;
The OfType() filters your collection to a subtype in your hierarchy. If you skip the OfType you will get both customers and leads in your resulting query.
I am having trouble understanding ORM in Ruby on Rails. From what I understand there is a 1:1 relationship between tables/columns and objects/attributes. So every record is an object.
Also what exactly is a Model? I know it maps to a table.
What I'm really after is a deeper understanding of the above. Thank you in advance for your help
I'm a Web developer going from PHP to Ruby on Rails.
"From what I understand there is a 1:1 relationship between tables/columns and objects/attributes. So every record is an object."
That is not exactly correct, unless you use the term "object" very loosely. Tables are modelled by classes, while table records are modeled by instances of those classes.
Let's say you have a clients table, with columns id (autonum) and name (varchar). Let's say that it has only one record, id=1 and a name="Ford". Then:
The DB table clients will map to the model class Client.
The record will map to a model instance, meaning that you have to create the object and assign it to a variable in order to work with the record. The most common way would be to do ford = Client.find(1)
The two columns of the table will map to methods on the ford variable. You can do ford.id and you will get 1. You can do ford.name and you will get the string "Ford". You can also change the name of the client by doing ford.name = "Chevrolet", and then commit the changes on the database by doing ford.save.
"Also what exactly is a Model? I know it maps to a table"
Models are just classes with lots of very useful methods for manipulating your database. Here are some examples:
Validations: Besides the typical db-driven validations ("this field can't be null") you can implement much complex validations in ruby ("this field must be a valid email" is the most typical one). Validations are run just before you invoke "save" on a model instance.
Relationships: The foreign keys can also be mapped onto models. For example, if you had a brands table (with its corresponding Brand model) associated via a foreign key to your ford client, you could do ford.brands and you would get an array of objects representing all the records on the brands table that have a client_id = 1.
Queries: Models allow you to create queries in ruby, and translate them to SQL themselves. Most people like this feature.
These are just some examples. Active record provides much more functionalities such as translations, scoping in queries, or support for single table inheritance.
Last but not least, you can add your own methods to these classes.
Models are a great way of not writing "spaguetti code", since you are kind of forced to separate your code by functionality.
Models handle database interaction, and business logic
Views handle html rendering and user interaction
Controllers connect Models with Views
ORM in Rails is an implementation of the Active Record pattern from Martin Fowler's Patterns of Enterprise Application Architecture book. Accordingly, the Rails ORM framework is named ActiveRecord.
The basic idea is that a database table is wrapped into a class and an instance of an object corresponds to a single row in that table. So creating a new instance adds a row to the table, updating the object updates the row etc. The wrapper class implements properties for each column in the table. In Rails' ActiveRecord, these properties are made available automatically using Ruby metaprogramming based on the database schema. You can override these properties if required if you need to introduce additional logic. You can also add so-called virtual attributes, which have no corresponding column in the underlying database table.
Rails is a Model-View-Controller (MVC) framework, so a Rails model is the M in MVC. As well as being the ActiveRecord wrapper class described above it contains business logic, including validation logic implemented by ActiveRecord's Validation module.
Further Reading
Rails Database Migrations guide
Rails Active Record Validations and Callbacks guide
Active Record Associations guide
Active Record Query Interface guide
Active Record API documentation
Models: Domain objects such like User, Account or Status. Models are not necessarily supported by a database backend, as for example Status can be just a simple statically-typed enumeration.
ActiveRecord:
Provides dynamic methods for quering database tables. A database table is defined as a class which inherits ActiveRecord class (pseudo-PHP example):
class User extends ActiveRecord {}
//find a record by name, and returns an instance of `User`
$record = User::find_by_name("Imran");
echo $record->name; //prints "Imran"
//there are a lot more dynamic methods for quering
New records are created by creating new instances of ActiveRecord-inherited classes:
class Account extends ActiveRecord {}
$account = new Account();
$account->name = "Bank Account";
$account->save();
There are two pieces here: the ORM and Rails's MVC pattern. ORM is short for "object-relational mapping", and it does pretty much what it says: it maps tables in your database to objects you can work with.
MVC is short for "model-view-controller", the pattern that describes how Rails turns your domain behavior and object representations into useful pages. The MVC pattern breaks down into three chunks:
Models contain a definition of what an object in your domain represents, and how it is related to other models. It also describes how fields and relationships represented in the object map to backing stores (such as a database). Note that, per se, there's nothing about a model which prescribes that you have to use a particular ORM (or even an ORM at all).
Controllers specify how models should interact with each other to produce useful results in response to a user request.
Views take the results created by controllers and render them in the desired way. (By the time you get to your view, you should mostly know what's being rendered, and there should be very little behavior happening.)
The definition from Wikipedia:
Object-relational mapping (ORM, O/RM,
and O/R mapping) in computer software
is a programming technique for
converting data between incompatible
type systems in relational databases
and object-oriented programming
languages. This creates, in effect, a
"virtual object database" that can be
used from within the programming
language.
From a PHP view it will be in the following way(via example)
Connect to the database and get some row from posts table.
Turn that row to an object with attributes like those in the table columns.
If the posts has comments in comments table, you can also do post.comments and you get the comments also as an array of objects as well.
You can define relationships between tables like saying: Posts has_many Comments, a Comment belongs to a post and so.
So basically you are not working with database rows, instead you turn those rows and their relationships to objects with composition or inheritance relationships.
In layman's terms.
A Rails Model is proxy to a table in the database. These models happens to be Ruby classes.
The objects of these classes are proxies to rows in the table of which this model is a proxy.
Finally the attributes of these objects are proxies to the column data for that particular row.
Above is actually the Rails ActiveRecord ORM.
1:1 is not quite correct, since there is object-relation impedance mismatch.