Home Help Center

OR mapping questions

stephanstephan Member Stephan StapelOrganization: Stephan StapelProject: BristolNG
Hi there,

I have some questions around OR-mapping. I would like to use a relational database as the backend and transport the data from/ to the database through Ice objects.

I.e. I would like to implement something like this:

CCustomerPrx customer = myInterface->retrieveCustomer("CustomerId");


However, I'm facing two major problems so far and hope for a solution :)
The goal for the application is to provide customizability for the objects attributes.
I.e. I don't know during design time if I have an interface definition like this:


class CCustomer
{
int id;
string address;
};


or


class CCustomer
{
int id;
string address;
float balance;
};


The only way I currently see is to use a hash map for filling and accessing these "uncertain" attributes.

Thus


class CCustomer
{
int id;
StringMap attributes;
};


Unfortunately, Strings are as typesafe as Any was. Thus I would need some access functions for safe type conversion.
However, I see another option like this:


class CCustomer
{
int id;
AnyMap attributes; // sorry for that
};

Using this variant, one could throw exceptions if the map access isn't typesafe, e.g. (meta code!)

customer->getAttribute("date").toInt() throws an exception whereas
customer->getAttribute("date").toDate() doesn't

However, I'm not sure if this is the easiest and most effective way to implement this. Not to speak about the manipulation of the relational schema that is behind this.


The second problem is inheritance. Let's say I want to have a base class (during runtime!) called CPerson and a derived class called CCustomer.

How would I implement this using Ice? The only way I see is something like this:


class CEntity
{
int id;
string type;
AnyMap attributes; // again
};


Obviously, these approaches to the two problems kill all typesafety. However, I'm fearing that I have to lift classes and attributes by one level in order to be able to implement this schema at all. Am I wrong with that and is there a possibility in Ice to implement such things? E.g., could the type-ids be used for such aforementioned inheritance case?

I'm sure that this is a quite difficult issue but I would be more than happy if we could discuss it here.

cheers,

Stephan

Comments

  • matthewmatthew NL, CanadaMember Matthew NewhookOrganization: ZeroC, Inc.Project: Internet Communications Engine ✭✭✭
    stephan wrote:
    Hi there,

    I have some questions around OR-mapping. I would like to use a relational database as the backend and transport the data from/ to the database through Ice objects.

    I.e. I would like to implement something like this:

    CCustomerPrx customer = myInterface->retrieveCustomer("CustomerId");

    ...

    cheers,

    Stephan

    Is it really necessary to take this approach -- as opposed to defining the actual objects themselves? Does your application let the end-user add new fields to the user records? If this is actually the case do you really need language type safety? Perhaps if you described your use-case a little more completely it would be easier to help you.

    Regards, Matthew
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    If you really need to create types that are not known at compile time, I recommend that you have a look at the Dynamic Ice chapter in the Ice book.
    And then look at the Ice for PHP and Ice for Python source code for code samples.

    Using Dynamic Ice, you could easy send and receive a struct whose definition is not known at compile time. It's also doable with objects, but it's more complicated.

    Naturally your code would need to know how to handle these dynamically-typed parameters ... you could for example provide a description in another parameter (with a type known at compile time).
    This is like typecodes in CORBA; Ice does not provide anything like typecodes, but you could easily build your own application-specific "type codes" and pass them as regular operation parameters.

    Cheers,
    Bernard
Sign In or Register to comment.