Felipe Lopez

Send private message

You must be logged in to send a private message.

Friends

No friends yet.

Group membership

Activity

  • Felipe Lopez replied on the discussion topic Error with au sub_groups plugin
    This problem still exists but the official site is now up at http://altmed.rocks view reply
  • Felipe Lopez added a new discussion topic Error with au sub_groups plugin in the group Elgg Technical Support
    It is installed and working on elgg 1.11.2 but adding a sub-group or viewing all gives me an error. It still seems to work but ... There is more but that is the start of the message. The site is http://ah.coinz.sx. It also suggests the...
  • Felipe Lopez replied on the discussion topic Adding user "information"
    The performance issue concern is for what I called "statistical data". The elgg instance is not the primary load on the site -- it is email traffic. There is the potential for a lot of updates to this information. While the fields that will be... view reply
  • Felipe Lopez added a new discussion topic Adding user "information" in the group Beginning Developers
    I am working on a system where I need some "accounting fields" for users. Some will be user-supplied (billing information, for example), some will be administrator supplied (access controll to non-elgg features) and some will be statistics from a...
    • What kind of performance issues are you expecting from using metadata?  Without knowing any specifics I would say there shouldn't be any issues.

       

      In terms of what you have listed there as options I would rank them as

      #1. Use profile manager and/or a custom plugin (very much the recommended approach)

      #2. Create a new table (though be warned now that you won't be able to use any of the elgg api to do anything with it and the data there won't be subject to the elgg access model): I see this only as a benefit to someone who hasn't learned the elgg data model and is hacking, in the long term this probably will backfire.

      #3. Extend the users_entity table: no, don't even attempt it

    • The performance issue concern is for what I called "statistical data". The elgg instance is not the primary load on the site -- it is email traffic. There is the potential for a lot of updates to this information. While the fields that will be changed by the user and the admin would benefit from the elgg access model, this data would be updated externally and be read-only for elgg use or possibly not even used.

      Your comments make me think that I may be better off breaking this into two different things. Handling the "close to static" information with the profile manager and putting the stuff that could be changing rapidly into a new table.