These are chat archives for systemaccounting/mxfactorial

24th
May 2016
irwynks
@irwynks
May 24 2016 17:23
Hi!
Max Funk
@mxfactorial
May 24 2016 17:27
Hello, Kishan will be on tomorrow to capture the values using the form, save them in the app's state, then submit to the api you're building.
irwynks
@irwynks
May 24 2016 17:28
Awesome. As long as I can get the keynames/sample of the request body I should be good to go on my end.
Max Funk
@mxfactorial
May 24 2016 17:30
{
  "account": {
    "auth" : {
      "user": "string",
      "password: "string"
    },
    "profile": {
      "first_name": "string",
      "middle_name": "string",
      "last_name": "string",
      "country_name": "string",
      "street_number": "string",
      "street_name": "string",
      "floor_number": "string",
      "unit_number": "string",
      "city_name": "string",
      "postal_code": "string",
      "telephone_country_code": "string",
      "telephone_area_code": "string",
      "telephone_number": "string",
      "date_of_birth": "string",
      "industry_name": "string",
      "occupation_name": "string"
    }
  }
}
irwynks
@irwynks
May 24 2016 17:31
Even awesomer. Thanks!
Max Funk
@mxfactorial
May 24 2016 17:33
The auth vs. profile nesting exists because, as people change their profile, mxfactorial will persist historical versions.
Transaction records will not store profile data; only reference the profile data using keys.
irwynks
@irwynks
May 24 2016 17:35
Makes sense. Why persist historical versions?
Max Funk
@mxfactorial
May 24 2016 17:36
From systemaccounting/mxfactorial#1:
The SandyDentist user records Los Angeles as her profile city. Sandy earns 1,200.00 for providing a root canal to another user. Sandy changes her profile city to San Francisco the following month after moving. Danny lives in Los Angeles and wishes to know what the average price of a root canal was in Los Angeles the previous month. Unless transaction entities duplicate user_profile data, the SandyDentist root canal transaction record will be excluded from Danny's query. Persisting & indexing historical versions of user_profile entities avoids i) duplicating user_profile data in transactions, and ii) compromising data (entropy).
irwynks
@irwynks
May 24 2016 17:37
Ahh yes
So oldprofile data will be stored with a date_created and date_deactivated?
or date_updated/date_deactivated
Max Funk
@mxfactorial
May 24 2016 17:39
Yes, but most recect date_created = date_deactivated of previous record.
irwynks
@irwynks
May 24 2016 17:40
Yes
Max Funk
@mxfactorial
May 24 2016 17:40
Therefore, date_created will suffice.
irwynks
@irwynks
May 24 2016 17:40
In the long run it might make more sense to denormalize
And keep that duplicate?
*duplicate entry
Reduce query complexity?
Max Funk
@mxfactorial
May 24 2016 17:41
You wish to store profile data in the transactions?
irwynks
@irwynks
May 24 2016 17:41
No lol
I wish to keep the date created. So that you dont have to query to find the last profile to find date deactivated.
Wait no. Opposite.
Max Funk
@mxfactorial
May 24 2016 17:43
Database indexing minimizes these expenses. Whatever's most efficient.
irwynks
@irwynks
May 24 2016 17:44
I wish to keep the date_deactivated. So that you dont have to move to another element to find the newer profile to find date_created.
Max Funk
@mxfactorial
May 24 2016 17:47
Very well. Not going to refuse such details at this stage of the project. Right now, the priority is to build for the engineering community & the public the platform.
...to model an economy the way the universe models us :)
irwynks
@irwynks
May 24 2016 17:48
Lol. Yea. That was pretty trivial. Just spewing my thoughts out loud (in text?)
Max Funk
@mxfactorial
May 24 2016 17:49
All theories on efficiency gains are welcome.