What is the recommended way to use the easyauth library

[kevinresol]

If I wanted to add more fields to the User model (e.g. Full Name, Email, etc....or just link a UserProfile using HasOne), is it possible to extend the User class?

[jasononeil]

In my apps I've used a UserProfile style class, with a one-to-one relation (UserProfile belongs to User). This is a fairly workable approach and what I'd recommend for now.

In general the way we map Tables<->Classes makes it far easier to work with composition (include related objects as a property) rather than inheritance (subclass with related properties).

If we were to try support some kind of inheritance, would you:

• Use the same table name for the sub class, or create a different table?
• If using different tables, attempt to use join queries?
• If using a sub class, would you want to be able to tell related objects (like Group) to reference the sub class rather than the super class? I suppose it could be achieved with generics but I haven't investigated.

Given these, it's tempting to say "use composition rather than inheritance" to keep things simple.

I'd like to hear your thoughts about possible direction to take here @kevinresol

[kevinresol]

I also use a UserProfile class, but in that case I cannot do user.profile unless I hack into the User class and add that. Futhermore, I would like to add some fields to the Group class, maybe type which again would not be possible unless I hack into the easyauth lib.

Inheritance in database sounds a bit complicated to me. Honestly I don't have much experience regarding (relational) databases. But let me give it some thoughts:

Suppose there is a parent class and 2 child classes, I think there should be 3 tables in the db. Since one parent class may be extended by more than one child class. So using the same table wouldn't work.

Say: (ripped pseudocode) class A { var i;} class B extends A { var j;} class C extends A { var k;}

Then we have a, b, c three tables: a will simply hold 2 fields: id and i b will hold id, j, parent_id c will hold id, k, parent_id

When you attempt to fetch an object like C.manager.get(1) it is going to join c,a ON c.parent_id == a.id

If there is a class D {var c:C;} then when you access d.c it is going to use the cID to fetch data from table c join a For class E {var a:A;} it will simply fetch from a. But then the problem is that you can't cast e.a to B or C in haxe code, because we don't actually know its type from table a. (so may be we need to store a child_id & child_type in table a as well?) Also, in that case table e cannot simply store an aID, it also need to store aType such that it would create the correct object in haxe.

Theoretically I think it is somewhat feasible. But doesn't seem to worth the effort in current stage of ufront. I guess the easyauth lib can act as a sample code library for people to start with.

Not sure if off-topic, but I noticed that there is a "relationship" table created in my database. I think the @noTable meta is being ignored. Is it supported by SPOD or only introduced in ufront? (I used the code in Tasks.hx in the hello repo to create the tables)

[kevinresol]

Cleaning up my old issues and I think this is no longer needed.