[DISCUSSION] Object Relational Mapping (ORM) for different programming languages

Thorsten Hohage thohage at objectmanufactur.com
Wed Oct 10 12:55:13 CDT 2007


Hi,

On 2007-10-10, at 18:26, Ruslan Zasukhin wrote:

> On 10/10/07 12:48 PM, "Philip Mötteli" <philip.moetteli at econophone.ch>
> wrote:
>
>>
>> Yes, it is.
>> The first part though, where he declares the relationship, has to be
>> implemented in a OR-library, so that it is reflected in the db.
>
> Or even better on db engine level, right?


I'm not sure, how much everybody participating this topic really  
knows about Ruby / RubyOnRails, so here some words...

While RoR being a really, really cool Framework, Language,  
Concept, ... there are some limitations. No, not that bad "OMG what a  
BS" limitation, but you should know about.

1) I.e. localization was (somepart is) still difficult. Of course you  
can change everything, everywhere and even better you could use very  
cool OO patterns to do it, if you decide to go this way, then a lot  
of these "easy one liners"  are rather comlpex to do

2) one of these "limitations" are the names handling, and e.g some  
"links" must have fixed names. Given a table is named invoice, then  
the linked id must be named invoices_id(! from memory, name may  
differ, but the concept is right). Furthermore the name of the UID is  
fixed!

I know several large projects which rejected RoR due to renamig the  
whole matured DB was not possible and breaking this with your own  
namening concept belongs to 1). Even worser when you need to use e.g.  
German names, where this concept breaks german grammar.


You can add several more point with restrictions on RoR. BTW. Ruslan  
DB vendors don't like RoR !!!!!! - because RoR is so abstracted, that  
only based statements are send to the db, no SP, Joins, ... so be  
careful what you suggest.

--------

I know I can't explain everything necessary to get behind the full  
concept. But In my ORM for RB (DynamicDataObjects - DDO) you can use  
a code style, but in most cases you don't need to touch any code, but  
use an external XML file.

So in Code style you say

In the constructor of an inherited class you say

   App.DDO.SchemaManager.AddJoinToObjects( _
   "optionValues","", "DBOBasicOption", "idserial", _
   DDOSchema.CREATE_NOTHING, DDOSchema.CLONE_CLEAR,  
DDOSchema.DELETE_CASCADE, _
   DDOSchema.JOIN_MANY, _
   DDOSchema.PREFETCH_YES, DDOSchema.DESERIALIZE_YES, _
   "option", "", "DBOBasicOptionValue", "basicOptionSerial", _
   DDOSchema.CREATE_NOTIFY, DDOSchema.CLONE_CLEAR,  
DDOSchema.DELETE_NOTIFY, _
   DDOSchema.PREFETCH_NO, DDOSchema.DESERIALIZE_NO)

where

"optionValues" - name of the join on "parent" side
"DBOBasicOption" - parent class name
"idserial" - name of the UID for this class (=table)

"option" - name of the join on "child" side
"DBOBasicOptionValue" - child class name
"basicOptionSerial" - name of the id in this class (=table)

to acces the values I used KVC keyValueCoding so i.e. I used GetValue 
("(some more here). optionValues.Option") to acces a value in a  
joined class.


In a high level Framework on top of the DDOs the statement is far  
shorter

	DefineMeAsInfoItem("GLOSSERPMaster", "currencys","","erp","")

"GLOSSERPMaster" - parent class name
"currencys" - name of the join on "parent" side
"erp" - name of the join on "child" side

But of course, THERE are the RoR issue back, because using this  
framework will force to need fix names, (of course in contrast to RoR  
and much better, there are few constants to change the fix name you  
like)


But in most cases you didn't need any class for extend business  
logic, so you can specify such a join as an xml "line"

<schemaJoins valueType="ddoBasicDynamicInterface"  
dynamicClassName="DDOXMLSchemaJoinData" 	
		schemaName="DDOXMLSchemaJoinData">
	<schemaJoin objectId="3325" so_serial="3301"  
parentObjectName="MFVisitors"
				parentJoinName="companions" parentIDName="idserial"  
parentPrefetch="True"
				parentCreateAction="Nothing" parentDeleteAction="Cascade"  
parentCloneAction="Clear"
				childObjectName="MFVisitors" childJoinName="visitor"  
childIDName="visitor_id"
				childPrefetch="FALSE" childCreateAction="Nothing"  
childDeleteAction="Notify"
				childCloneAction="Copy"/>
</schemaJoins>

I just finished an exhibition visitors management system using only a  
XML definition without any class defined in RB.


---

When now thinking about integrating my framework more with Valentina,  
then all this logic can be placed in table properties and scanned for  
ObjectPtr / BinaryLinks / ... and you're ready to go even without  
such a xml file. No class, no additional configuration, just Valentina.


regards

Thorsten Hohage
--
objectmanufactur.com - Hamburg,Germany




More information about the Valentina mailing list