Menu

three questions to ask,^-^

Help
2006-02-27
2013-04-13
  • Nobody/Anonymous

    dear,
        everyone.Thanks a lot in advance!Any help would
    be very very appreciated.
        After reading the help doc about ORM,I have three
    questions to ask.
        The first is when I create a record in table by
    calling $class->new(...) method.Must the name of
    property in class be the same as the name of field in
    table stored in database.If not so,How can i do?After
    reading the helping doc,i know the default behavior is
    to create the same field's name as the property's name.
        The second is as follows.Must the number of properties
    in class be the same as the number of fields in table.
    For example,I have a class with three properties named
    'name','age' and 'gender'.And I have a table with two
    fields named 'name' and 'age'.That is to say i don't want
    to store the value of property 'gender' into the table.
    How can i do?I can not find the answer in the doc so
    please help.
        The last one is about inheritance.To implement
    inheritance ORM uses so called vertical mapping.I do
    not want this mapping.What i want is that for every child
    only one table should be created.This table contains
    child's direct properties and the inheritted properties
    of base classes. Is there any way to achieve this?
        Hope i have said clearly.Thanks again.

        mosquite

     
    • Alexey

      Alexey - 2006-02-27

      1. Now there is no ORM.pm generic way to rename or alias properties. It can be relatively easy implemented in your initial class to use arbitrary renaming rules (including hash-mapping) by overloading 'new', 'update' and 'property_id' methods. If this is your case then I can help you with implementation, moreover it can be helpful for others.

      If you simply want to rename property's accessor/mutator, you can try:
      sub new_name { shift->old_name( @_ ); }
      But you still have to use canonical property name with 'new' and 'update' methods.

      2. Initially any object of the ORM-class has number of properties equal to number of fields in table, but you always free to add any additional properties in very usual way.

      3. There are no inheritance schemes planned to implement other than vertical mapping at present.
      Implementing horizontal mapping is not in todo list also because of its limited functionality. But if you please to tell me about the way you plan to use horizontal mapping it definitely will be considered.

       
    • mosquitee_eshen

      mosquitee_eshen - 2006-02-28

      First thanks for your reply.
      About the second question.If I call
      $s=Test::Student->new(prop  =>
            {
                name    => $name,
                age      => $age,
                gender     => "Female"
            },
      ) method when the student table in database
      only have fields named 'name' and 'age',
      then does an error returns?Does the same
      situation applies to the Test::Student->update(...) method?

      Moreover,Does ORM support the backend database
      of postgresql?If so,how can i do?

      Thanks againg.All the best wishes to you!

      mosquite

       
    • Alexey

      Alexey - 2006-02-28

      1. Could you please explain how you plan to use this? As far as I can imagine, properties those have not be stored in database must be initialized from storable properties or from implicit values. Opposite way is to initialize storable properties from non-storable. Both cases are achievable by redefining 'new' and 'update' methods to handle non-storable properties.

      While not redefined 'new' and 'update' methods silently ignore superfluous properties.

      2. You can count on ORM v0.83 which already contains initial version of PgSQL storage driver. I have planned to upload it this week.

       
    • mosquitee_eshen

      mosquitee_eshen - 2006-02-28

      First appreciated much for your reply.
      1.Forget about class with superfluous non-storable properties,actually this situation does not matter so much.Just like what you said,both cases are achievable by redefining methods.

      2.Looking forward to the release of ORM v0.83,the backend database in our application is postgresql.So welcome it with great ardency.

      3.What i am thinking is that why not use a configuration file just like hibernate did.In this way,we can achieve higher flexibility.For example,it is easy to rename or alias properties into different fields in table.And also we do not need to record the relations between classes in the table '_ORM_refs'.

      I'd like to hear your ideas about this problem.If i want to do like this,how much the difficulty is and how much work i should do?Can you give me some advice.

      thanks a lot.May you have a happy working day!

      mosquite

       
    • Alexey

      Alexey - 2006-02-28

      It will not take too much time to implement support for configuration file and moreover it can be implemented to make users free to choose between config file and __ORM_refs. Also it is important to me to know why do you prefer config file agains __ORM_refs table.

      But problem is not in the way the configuration stored, it is in the absence of renaming ability.It have to be implemented either as biuld-in or build-on to ORM.pm.

      I have one interesting feature called "Implement multifield properties" near the top of my TODO. This feature is the superset of renaming/aliasing problem. I very appreciate your feedback, so I consider this feature as target for v0.84, which might be available around May 12. I try to do my best to make things done as soon as possible.

      I suppose that you want properties to have names different than field names because you try to make ORM work with existing database. Am I right or is there another reason?

       
    • Alexey

      Alexey - 2006-02-28

      Also, if you consider it possible to contribute to ORM, then you are welcome to improve PgSQL driver, fix possible bugs and handle Postgres generic functions.

       
    • mosquitee_eshen

      mosquitee_eshen - 2006-03-01

      About my wanting properties to have names different than field names,you are very right.I want to make ORM work with existing database.How do i achieve this before releasing ORM v0.84.What advice from you?^-^

      Why i prefer configuration file to _ORM_refs table?Below is just my point.
      First,it is natural to config something throught configuration file just like ordinary applictions do.Just by editing file but not by inserting records to table. That's is to say this way might accord with our habit.
      Second,it is easier to do complex configuration throught configuration file.A two dimensional table to some degree does worse than configuration file in recording complex configuration info.It is more natural to support renaming function by using configuration file just like hibernate did.

      And I also be glad to contribute to ORM.It is my pleasure to improve PgSQL driver.Futhermore maybe i can also do something about implementing support for configuration file. But doing latter thing,i need helps from you.

      Thanks for the work you have did.well-done!May you have a happy working day!

       
      • Alexey

        Alexey - 2006-03-01

        Thanks a lot for your feedback, There is only one question left to go, do you use fields named 'id' as primary keys in your tables? Are there exceptions to this rule may take place?

        Now I'm going to go through the following steps:
        1. I will upload v0.83 with PgSQL support in 10-12 hours, so you can play with it a little.
        2. It will take around a couple days more to provide you with ability to use config files and quick workaround to rename properties.
        3. ORM's DB-layer should be documented to make it possible to contribute to PgSQL driver.

        You can contact me by ICQ 151482811 to take quicker support on PgSQL driver.

         

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.