Is there ever likely to be the option, to imp...

(David Ackling-Jones) #1

Is there ever likely to be the option, to implement polymorphic dependency injection via interfaces, that can be implemented by multiple different tables that follow that interface’s structure?

I have built a CRM in Appsheet that is managing an increasing number of business activites in my business, and I am concerned that there are way too many logic loops based on queries between tables, to maintain the app long term, as things change and grow.

Going forward, I would like to refactor the app, so that there are a lot less conditional expressions, and I can encapsulate the state of each record–i.e. I don’t want my calculated rows to be changing in unpredictable ways, as things get more complexly interelated across tables.

Has anyone gone down this track of trying to do something like SOLID object oriented design, in Appsheet?

(David Ackling-Jones) #2

@Stephen_Mattison I have 37 tables in the app and growing… Many of the properties of the records in each table are dependent on the state of related records in other tables. So a change in a record or design in one table can have unforseen effects in other tables. You see this as an error message sometimes, but there are errors that appsheet does not know to check for as there is no unit testing capacity on Appsheet. Eg. Each record in my Timetrack table has a required dependency on a record in each of the following tables:



Calendar Entry

Service Booking

Service Booking Detail

Contractor Invoice and

Payment Request And each Timetrack record has many records in the tables

Action and

Image And that is just a list of the dependencies for one of my tables. Can you see any possibility one day that I make a change to one thing and then lose 12hrs repairing the app? Makes me scared of changing things and leads to app rot. Soon (hopefully not too soon) we will need to move to a code centric platform like .net so we can refactor the app to be more robust. Very grateful to be able to prototype it all in appsheet though!

(Bellave Jayaram) #3

I don’t fully understand what you are asking here but why should there be a concern about the number of logic loops based on queries between tables as long as there are no cycles in the queries and no race conditions? Is the thinking that queries may be syntactically correct but could become semantically incorrect due to some obscure change down the road thus causing some rows to change unpredictably?

(David Ackling-Jones) #4

A future change in one table may cause unpredictable and unwanted changes in other tables, or break things. Google “SOLID principles of OOP”. Cheers, D.

(David Ackling-Jones) #5

The biggest reason I want to minimise conditional expressions is that it takes a long time now to sync the app, and when I make a change in one place I don’t want to have to make 100 other changes to fix the side-effects–it is taking too long now.

(Stephen Mattison) #6

@David_Ackling-Jones Wish I had something for you here bro.

I have a feeling the AS dudes would tell you to split this monster into several Apps.

As a multiple business Owner, I like to cram as much as I can into one App, so I can just live in there, but your description sounds hairy!

It would be neat to see an image of your Spec View for this App, where we can see how everything is connected.

The very cool new Search View might be great for you.

Have you played with that yet?

Pretty powerful!

It seems to act like a “Slice on the fly”.

(David Ackling-Jones) #7

Cool @Stephen_Mattison I wil check out the Search View, I have not been aware of that yet. Here is my spec view, it is a bit insane.


(Stephen Mattison) #8

@David_Ackling-Jones You might need to ask to be added to beta of Search View, which AS just now changed to “Assistant” View.

If you have access, you’ll see it available when you go to add a new View.

(Praveen Seshadri (AppSheet)) #9

@David_Ackling-Jones, it sounds like what you need is two things: (a) the ability to define data constraints — to handle the data dependencies you have and (b) the ability to change column names and have that seamlessly modify all the expressions.

I’m not really sure you need polymorphism and OO design. That usually does not fit very well with database persistence (despite a lot of efforts over time).

(Praveen Seshadri (AppSheet)) #10

Hi @David_Ackling-Jones, it is difficult to do true object-oriented design in a data-centric platform. Tough in SQL, tough in AppSheet. AppSheet already has the concept of entities (equivalent of classes in OOP). We could, in principle, grow AppSheet to have the notion of private and public columns (properties) and private and public actions (methods). Also in theory, we could augment the data model to cover concepts like inheritance, polymorphism, etc. From the history of database systems, this is very similar to what object-oriented databases tried to do in the 90s and failed to get market traction — there were relatively few data-centric applications that needed it.

(David Ackling-Jones) #11

That would be brilliant Praveen!!

(Praveen Seshadri (AppSheet)) #12

To be clear David, I am not saying we will do this. In fact, I’m pretty sure we will not do it in the foreseeable future (for precisely the reason that the OO-DB vendors failed in the 90s — it appears that the vast majority of data-centric business apps don’t really need the richer OOP mechanisms).

I’m just saying I think I understand what you are asking for.

(David Ackling-Jones) #13

It would be amazing to have an abstract table that only had calculated fields, and could be implemented by more than one table.

(David Ackling-Jones) #14

Thanks so much for responding Praveen. Your app is brilliant.

(Stephen Mattison) #15


Can you share (lots) more about one or two of your logic loops and/or conditional expressions that you are concerned with becoming a problem in the future?

What is the nature of your business?

It would help to understand more about the issues here and make suggestions.

(David Ackling-Jones) #16

I am starting to implement a type of Polymorhphism into my app by referencing Slices rather than tables in my ref columns, but it is a bit messy to say the least.

Eg. My “Person” table has a column [PersonType] enum which can = Client,

= FamilyMember, or = Staff. I have a slice for each [PersonType] that makes different columns public depending on the [PersonType]. e.g. Only the “Person_Staff” slice exposes the column Person[StaffID]

In the “Person” table, I set each property on each column (e.g. RequiredIf) with a conditional experession depending on the [PersonType] e.g. the RequiredIF and ShowIf properties of Person[StaffID] are if


So this is a way to have several different types of Person behave and compose themselves differently, without creating a different entity to hold them.

The messy thing is the proliferation of conditional expressions required to manage this pattern–If we could just be able to implement an abstract Table with multiple concrete tables that would be AWESOME.

Really keen to share ideas with others who are making apps that are getting a bit too large for comfort, and are using patterns to manage the chaos.