Akelos Framework v1 forum archive. This forum is no longer maintained. To report bugs please visit https://github.com/akelos/akelos/issues
    • CommentAuthorzilpin
     
    I'm having problems with the plurals convention. It makes it difficult for me to follow existing database naming conventions in my company, and is (right now) why my proposals to spend company resources on investigating Akelos are denied. Why does everything have to mangle names so much? Were prefixes (a la Hungarian) or suffixes not enough?
    How should "Person" be defined? As "People" or "Persons"? How should something like "RawData" be pluralized? Names like "Student", "Teacher", and "Subject" are easy, but what about "Class"?
    Is Akelos really clever enough to automagically apply English rules correctly, every time, for plurals? The tutorials and guides imply this, but that seems like a lot of wasted effort.
    Is there any way to configure Akelos to not pluralize entities? Oops, I used the forbidden "C" word.

    Sorry for such a rudimentary question, but I've searched through the forums and documentation, but couldn't find anything which applies, and I can not access the wiki to see if there is anything in it.
    I would be very grateful for a "RTFM" response, and figure it out myself, if pointed to the right manual.

    Thanks.
    • CommentAuthorKaste
     

    You can always state the tablename explicitly

    ->setTableName('im_a_control_guy');
    

    The same goes for associations.

    Is Akelos really clever enough to automagically apply English rules correctly, every time, for plurals?

    no, not every time, but most of the time.

    • CommentAuthorzilpin
     
    Thanks for the quick reply!
    Won't using setTableName break the scaffolding tools, or other automation?
    Is there any way to change the conventions which Akelos uses, or are they all hard-coded?

    :-) I like that table name in your example. In my company, it would be more like setTableName('tableControlFreak")
    My company has loose coding standards, but strict database standards, so every table name must begin with "table", be in CamelCase, have no underscores, must be alphabetic only (numbers permitted on special occasions, like a table to store IRS 1022 tax information, etc), and must be in the singular tense. Having verbs in table names is frowned upon, but permitted if a "better" name can't be devised by a project manager. All entities follow similar rules, but I can get away with fudging column names. The biggest problem we'll probably have with Akelos has to do with primary key rules, but I'll worry about that later. We are supposed to avoid auto-increment IDs whenever possible. I will be using a loophole around our stored procedures rule, as we are banned from having any SQL in strings in code; any SQL in code must be moved to a stored procedure before QA begins. Since Akelos handles all the database interaction, I can follow the rule without creating any stored procedures, which I like.
    • CommentAuthorKaste
     

    I can follow the rule without creating any stored procedures

    that sounds positivistic.

    anyway, for whatever reason you're supposed to avoid auto-incrementing ids, since Akelos relies on this in a way you had to clone the db-adapter class.

    class myMysql_adapter...
    function incrementsPrimaryKeyAutomatically() // must return false
    function getNextSequenceValueFor($table)     // must return the next valid Id
    

    right now this would rely on using the branched-version of Akelos.

    and from now on we should consider naming variables with the prefix variable. ;-)

    • CommentAuthorzilpin
     
    OK, thanks for all your help.
    This will give me somewhere to go.