Question Pulling table data into a class

Ok, so this may be a dumb question but for whatever reason I can not seem to wrap my brain around how to do what I want to do.

So what I'd like to do is take some set of data from database tables, multiple records, and then store them into a class for use later. My first thought was to simply create a class with public properties that match up with the fields in the table. Make them all longchar. Then store the records in a delimited list in each of the fields. For example entry 1 of each property would be 1 record. Now one of the fields is already going to be a delimited list, of course I can use different delimiters, but i'd really like to not do that. I'd like to create multiple instances of the one class, without having to statically define them. I'm just not sure how, where to store each of these records. I'm sure it's an easy answer but again, my brain is not fully functioning today for whatever reason.

You seem to be randomly conflating properties, records, classes and fields.

I suggest more coffee.

Ok let me see if I can more accurately describe what I'm going for.

First let's define a table from the database:

tableTest
field1 int
field2 char
field3 char
field4 char

next lets define a class:

<code>
CLASS testData:

DEFINE PUBLIC PROPERTY Field1 AS INTEGER NO-UNDO
GET.
SET.

DEFINE PUBLIC PROPERTY Field2 AS CHAR NO-UNDO
GET.
SET.

DEFINE PUBLIC PROPERTY Field3 AS CHAR NO-UNDO
GET.
SET.

DEFINE PUBLIC PROPERTY Field4 AS CHAR NO-UNDO
GET.
SET.

END CLASS.
</code>

So then I would like to create and store an undefined number of instances of class testData.

This would be so that I could, on the server, loop through whichever entries from tableTest I need and create a unique instance of testData.

I hope that makes a bit more sense.

DB Record corresponds to "instance of a class".
Field corresponds to "property of the class".

More or less.

You could create one instance of the class for every record. Or you could have a single "active" or "in scope" instance and populate the properties behind the scenes. Sort of like a 4GL "buffer".

TomBascom said:

DB Record corresponds to "instance of a class".
Field corresponds to "property of the class".

Click to expand...

That is exactly what I'm going for.

I'd like to create an instance for every record, but I'm having trouble figuring out how to dynamically store them as I wont know how many I will need.

What do you mean by "dynamically store them"? That seems circular.

Depending on your Progress version you can "serialize" objects. But I'm not seeing what the point would be.

Why do you want objects that correspond to db records? What do you hope to do with them that is different from working with a record buffer? How is "storing them" different from storing db records?

FWIW one way to dynamically create as many as you would like within a session is to store them in a temp-table record with suitable data to help you identify and fetch them. But without knowing why you want to do this and what you hope to achieve it seems a lot like an exercise in OO for the sake of OO.

A conceptual issue is that there is no direct match for a temp-table in the OO world of languages like Java. Although there are libriaries that sort of mimic such functionality.

In Java you would creata a bean which has private attributes that match the fields of the database/temp-table record and generate getters and setters for them. You would them create a collection and put these beans into that collection and later on work on that collection. You would fetch beans you need and manipulate them. Or, you would use some library like I mentioned above.

IMHO - if you follow the same concept in the ABL - which you can - you would re-invent the wheel and abandond some of the great features of the ABL.

My current thinking is as follows:

I would create an ABL bean ( matching a single database/temp-table record having properties matching the fields ). Then I would create a collection class which does wrap the temp-table but hands out the bean instead of a buffer handle ( or additionally another method to provide the buffer handle ). This way you can utilize the power of temp-tables plus work with the individual beans ( records ) in a pure OO approach. Of courese you will have additional overhead in the getter and setter - creating a bean out of a temp-table record and vice versa.

IMHO - like with most design decisions - there is no black or white, but different shades of grey. Depending on the size of the collection ( number of records ) and the access pattern you might find the the above described approach to add a performance penalty which you might not want to accept, and, therefore decide to work straight on the buffer handle like most ABL logic.


Heavy Regards,
RealHeavyDude.

Ok so maybe I'm confusing everyone including myself.

The goal of this all is to get the contents of the table from the database out to my front end, which is entirely written in OO classes. I recall there is some issue with defining temp-tables in a class, as a result all of our previous screens have used a class that mimics the table structure. But in all those cases we only need one record. In my new case I will need all records that match certain criteria. I believe the issue has to do with defining temp-tables outside/inside of a method. I would need it to act more like a property and be globally available.

Finally, some context. I was about to post that there are many ways of handling this kind of situation, but the best way depends on context. E.g., there is nothing wrong with wrapping a TT in a class as long as everything outside the class is unaware that the TT is in there. But, for the specific issue of passing a collection of data from the data access layer to the UI layer, I would look at turning the data into JSON, passing it between layers as a simple string which will be agnostic to the technology of the UI layer and then use that in the UI with whatever structure fits the use.

What if I change up the question a bit?

What if instead I define a temp-table in one class and then say I want to access that temp-table directly from another class. As if the temp-table itself was a property of the class?

It would look something like this:

That is one thing you shouldn't do. Hide the implementation. Always.

What would you recommend then?

Provide the class with members for what you need. Encapsulate the behavior within the class and deliver results to the outside.