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 program processing a log file (data transfer, for example).
I am new to making elgg do what I want (that is, I have used it for a site but this is my first time considering modifications). Lots of design and programming experience (but not a lot in PHP).
I looked at the profile manager module but am (mostly) concerned with performance issues as information is stored in metadata/metastrings. I see three possible approachs:
My "guess" is that #3 would be the best approach but would appreciate some input from anyone with more elgg experience. Thanks.
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
- Matt Beckett@Beck24
Matt Beckett - 0 likes
- Felipe Lopez@felipe_nica
Felipe Lopez - 0 likes
You must log in to post replies.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.