http://www.perlmonks.org?node_id=577805


in reply to Re: DBIx::Class questions
in thread DBIx::Class questions

Hi jimbus,

Yes, my example was all in one file.. Thats generally considered the worse way to do it.. put them each in their own files if you can. (My excuse is, mine was created by the sql translator script, which can only output one file at present, and Ive been too lazy to change it ;)

Your schema looks fairly good to me, though I think you have the arguments reversed in that has_one().. In fact, Im not sure what relationship it's describing. You're saying each system row has an corresponding entry in the users table, with the ID from the system table in it? That doesnt look like what you mean. Is Point_of_Contact a role? Can you show some example data for that please?

C.

Replies are listed 'Best First'.
Re^3: DBIx::Class questions
by jimbus (Friar) on Oct 13, 2006 at 03:13 UTC

    You're right, I should be using a role in that place. I've had in my mind that a limited number of roles would be easiest to manage, but I don't think that's right either. But on the other hand, do I really want a role for each system/element/connection/etc on our network

    I'm also struggling from moving my mindset from normalized tables to object oriented constructs.

    What I want in the final analysis, is to have a list of systems (on a web page using Apache/Catalyst/Mason) in a tabular format with basic information displayed in the list, including the user id for the point of contact (or owner) of the system. Clicking on the system name will bring up more detailed information about the system (elements, trouble tickets, maintenace procedures and schedule, disaster recovery... I've put in those tables, but they are commented out, at the minute). Click in the PoC will bring up additional info about the owner, such as email and full name.

    I've built systems like this many times, but never in an object oriented fashion. I've always been a fan of OO and decided to try it, but I'm getting bogged down on the basic stuff... do I have to built the interrum tables, like the ones that mantain the relations between systems and roles or roles and users... when elements get added to the mix, do I add them through some interface on system or do I just add the element to the elements table update the relationship table by hand? For that matter... and I'm still reading... how do I retrieve the elements when I want to display them.

    an example of a system:

    • obid: 1<\li>
    • Name: Data Core<\li>
    • decrip: provides data flow for all traffic in the data portion of the network<\li>
    • Point_of_Contact: points to a user or role<\li>

    an example of a User:
    • obid: 42<\li>
    • username: aperson<\li>
    • password: [29134u[rmc qu&NAPEUT$peutq'tqwfj<\li>
    • firstname: Aparticular<\li>
    • lastname: Person<\li>
    • email: aperson@dobson.net<\li>


    --Jimbus aka Jim Babcock
    Wireless Data Engineer and Geek Wannabe
    jim-dot-babcock-at-usa-dot-com
      Yes, you should create a DBIx::Class file for each table, including the ones used to just link across, for a many-to-many (Funnily enough, theres a bridge method that creates many-to-many rels for you).

      How are the system/role/user tables actually set up? Given a "system", using SQL, how do you find the point_of_contact? That might be the easiest way of translating it to DBIx::Class.

      As for the elements, I don't know how they look like in the database either, can you maybe just post your create table statements, and we can go on from there?

      C.

        Unfortunately, I've invested more than a week into catalyst and trying to learn DBIx and have little to show for it. I'm at the point where I need to admit defeat and go with what I know... building psuedo-objects in my business logic layer and building my own plain, dirty sql tables and displaying with mod_perl and mason... at least I've progressed to the point that I know longer have my business logic wrapped up in my view code. :)

        Perhaps I'll try again later with something not so large and see if I can revisit this again later... but those sound like famous last words :(


        --Jimbus aka Jim Babcock
        Wireless Data Engineer and Geek Wannabe
        jim-dot-babcock-at-usa-dot-com