Abstract out each segmentRows argument

[septIO]

Since we're gonna need to do some heavy work with a SegmentRow's arguments, it would make sense to have it being their own class.

I suggest this solution:

class Segment{
    /**
    * @type: SegmentRow[]
    */
    rows
}

class SegmentRow{
    /**
    * @type: SegmentRowArgument
    */
    args
}

class SegmentRowArgument{
    /**
    * @type: string
    */
    name
}

Notice, I'm already working on this, this is just to ask for comments and for future reference

[septIO]

I further suggest we change the naming of the classes:
SegmentRow shold be renamed to Property
SegmentRowArgument would be renamed to PropertyArgument

[ajthinking]

Love the renaming! Fully agree also on making every piece into its own class, beautiful.

Heres a thought (not sure if good or overkill): Make SegmentRow abstract and then make implementations SegmentTitleRow and SegmentPropertyRow. Just in case there is a need for specific/shared functionallity down the road.

There is also a test section now, feel free to explore that and add tests where it makes sense :)

Thank you!

[ajthinking]

@septIO, can I get your email to send a private message?

[septIO]

kc.laukamp@gmail.com

[septIO]

@ajthinking Good idea with splitting the segment into TitleRow and PropertyRow, resolves the issue with continuously using segment.slice(1).join().

So, a segment is defined by sketch, a segment is test from a starting line, and all the way down to the first \n\n. The first "row" will always resolve to the segments SegmentTitleRow, what about many-many tables? Like car_garage, that would not have any following lines. Which means that the entityType will have to be resolved before the rest of the segment.

Let's have an Abstract Class called Entity. many-many will then be another class that just extends Entity.
So TableEntity extends Entity - car_garage is a TableEntity, while Car is a ModelEntity.
If we chose to got the TypeScript way, we could alias them to Table and ``Model` to keep it simple.

Let me know your thoughts of this

[ajthinking]

Not sure I understand fully,

The first "row" will always resolve to the segments SegmentTitleRow

Yes!

what about many-many tables? Like car_garage, that would not have any following lines. Which means that the entityType will have to be resolved before the rest of the segment.

We might want to add attributes to the PivotTableEntity sometimes though. And not necesserely do we need to resolve it first, if no further lines are provided the properties array will just be empty?

To complicate matters further we might also need a PivotModelEntity? Not sure if this is language agnostic approach, but in Laravel you may treat the intermidiate table as its own model kind of.

The current designs assumes every segment spawns a table.

https://drive.google.com/file/d/1BLTB5srjOostoVxViApsDbbtTgy4IiB-/view?usp=sharing

The lower ellips in the image is if we should support custom directives kind of like a "domain language". Not sure about that, it might make a mess of things.

Taking a step back, regarding the Many to Many, what do you think is the most fool proof language agnostic way to express that? model1_model2 is not obvious even for Laravel users.

[septIO]

The easiest, and best way to implement all of these at the sometime is by using a really good "pluralizer", and "singularizer".
A standardized way could be:
A_B // A hasOne B, B belongsTo A
B_A // B hasOne A, A belongsTo B
As_B // A hasMany B, B belongsToMany A
Bs_A // B hasMany A, A belongsToMany B
As_Bs // A hasMany B - with pivot

[ajthinking]

The easiest, and best way to implement all of these at the sometime is by using a really good "pluralizer", and "singularizer".
A standardized way could be:
A_B // A hasOne B, B belongsTo A
B_A // B hasOne A, A belongsTo B
As_B // A hasMany B, B belongsToMany A
Bs_A // B hasMany A, A belongsToMany B
As_Bs // A hasMany B - with pivot

Its a cool idea! So this would mean going down the configurationEntity ( or configurationSegment) route - such an entity wont always spawn tables on it own, but can instead infuse relationships and other things. Im still a bit sceptic about doing that, because it will introduce sort of a domain language in the sketch? Currently its data driven in the sense that each entity spawns a table.

Maybe we can use what you are suggesting but put that as parameters instead. It could support multiple approaches:

implicit foreign keys

Keep current approach for simple relationships:

Car
user_id

explicit foreign keys

Allow custom named foreign key:

Car
owner : foreign User

as TitleRowParameter

Use the TitleRow to attach relationships

Car : hasOne User
color

in case of many to many

User : hasMany Interest
name

Interest : hasMany User
name

We may still keep this convention:

User
name

Interest
name

interest_user

let the user be explicit about pivot Models

User
name

Interest
name

Hobby : PivotModel User Interest

or pivot Tables with custom names

Hobby : PivotTable User Interest

[septIO]

explicit foreign keys

Allow custom named foreign key:

Car
owner : foreign User

as TitleRowParameter

Use the TitleRow to attach relationships

Car : hasOne User
color

I really like this idea! Also removes the confusion of model1_model2 relations, which is which. And we will be able to set the exact relations, and reverse relations.

Car : hasOne User // Throw an error if no 'User' model exists
Car : hasOne User // Will automatically assign the reverse relation to the 'User' model, and make a user_id property

Car
owner : foreign User // automatically assigns 1-1 relationship
```

I can see two ways to make a many-to-many relationship:
```
Car : hasMany Garage
Garage : belongsToMany Car
```
Or
`car_garage`