emilio15 asked:

Can evolve_schema modify field properties on DB?

Tags: og db

Hi, this is my first post. I am looking for a ORM tool for a project. I became to OG, which seems superb for me. Evolve_schema is great, but I am wondering if it has a feature we have in our closed, propietary ERP: that of defining the schema AND REDEFINING it, and keep a Data Dictionary.

I try to explain: let have class Customer and class CustomerInvoice; we have in both classes a property (field in database table) CustomerId, say Varchar(5).

Many times is necessary to alter that property definition, say to Varchar(10). Does OG alter the table definition to reflect those changes? That is, can it identify that a field definition on table has changed and alter table with it?

Moreover, we have a Data Dictionary where we define a DD entity say CustomerIdType which should be defined as Varchar with lenght=5, and properties on both classes are based on it, say something like: property :CustomerId, CustomerIdType That type susbtituion, I have read, would be possible with OG, insn't it?

With both features you could imagin how flexible a database backed application could be implemented.

Is OG capable of it, or could be in near future?

(2 attempts)

emilio15 answered:

Thank you Kashia for your reply. If it helps, I'll try to describe what our ERP does. I know it very well since it is our main development tool here in our company; and I have to say that it is the most productive IDE and most thoroughly thinked database development environment I have ever worked with. I am talking about Axapta (it calls AOX to that IDE), formerly by danish Daamgard, then Navision and now owned by Microsoft as part of the Dynamics family.

I think you could easily find parallelisms and future enhacements in OG:

It has indeed definitions of each data entity -> "tables" with definitions of fields, indexes, relations AND methods, static or by instance. An instance of the "table" (class) represents a row, but suffers methods. With that definition you could easily think that a table behave as a class, with methods and properties being the fields; it does not support inheritance, though. Fields have properties such as type, lenght, decimals in case of Real numbers and others such as display length and label (with support for localization). Indexes are self explained. Relations, either explicitly defined here or implicitly by the Data Dictionary (more on that later). Methods could "static": their ambit is the whole class, or could be of instance. It has a language (close to Java sintax) where SQL access to tables are simple yet effective through methods and iterators on table instances. You can change a field type in many ways: eg.: string length, although if new lenght is shorter than previous you receive a message warning of possible data losses, from Integer to Real, from numeric to string and so on. I would think that more or less are the same type casting that ruby could do. Those changes reflect on on SQLServer(it is the only RDBMS that it supports) schema when you commit them . We NEVER ever open SqlServer manager at all. Do you find the similarities with ruby classes definitions and og?

Moreover, it has the Data Dictionary, a tool I was looking for since I left University. It defines DataTypes, such as CustomerIdType, inheriting from the Base Data Types(string, Real, Integer, DataTime, Bool, and Memo); but they could be redefined. Eg.: we have PartnerIdType, say String(10), and VendorIdType and CustomerIdType both derived from partner. So we have 3 data dictionary types. Fields in tables could be defined with one of them as their types (that is what you answered, Kashia). But it is possible to refine CustomerIdType to be say String(15). With an extensive use of data dictionary definitions and table fields based on them, have I explained what I mean? If ever we need to change our PartnerIdType definition to say String(30) we simply edit it on Data Dictionary, commit and wait for the system to alter all the tables where PartnerIdType, or VendorIdType were used.

More on data dictionary, a data entity such as CustomerIdType have a property which tells you if that is the single primary key of a table, in this case we say that it is the prymary key of table Customers. Now, when in any other table you add a field with CustomerIdType it declares IMPLICITLY a foreing key in the other table, say CustomerInvoices. It is used mainly to navigate through the data. All that information is sincronized with SqlServer.

I don't want to bore you. I just tried to explain a excellent implementation of a dabatabase ORM (which is what Axapta AOX is after all) that speeds programming a lot.

My point is that, as I analyze OG, it seems to me very close: an abstract Data Dictionary Entity to derive data types from them, type checking at startup, what more? When I came across OG, it surprised and excited me since I thougth it is what I was looking for so long in the open source area. However I just landed in Ruby area and is quite new to me. Could you send this info to the development team?

Hope it helps.

(sorry for my English) Emilio Arrufat

Rating: 0

Kashia answered:

I'm afraid to have to tell you, that Og currently (0.30/0.31) does not have that feature.

It will not track changes to the type of a property. In fact it will just try to update it, regardless of the type. It will produce SQL errors, if the types aren't compatible.

The second part is possible though (If I understand your definition of a Data Dictionary correctly).

def VarChar(size)
  return String, :sql => "VARCHAR(#{ size })"
end

def CustomerIdType
  return VarChar(5)
end

Now the CustomerIdType can used as a normal type:

class OgKlass
  property :customerId, CustomerIdType
end

I agree that checking the type on start time would make this system even more flexible and less error prone. I think this should be added, definitly. Thank you very much for that, may I say, feature request.

I will point George to this question, since he is working on an Og reorganization at the moment, maybe he can add this while he's at it.

Rating: 0