Results 1 to 10 of 14

Thread: The DataDictionary Liberation Request

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Default The DataDictionary Liberation Request

    This class is one of the great classes of Visual DataFlex and as I see it the main reason why you would use VDF at all.

    However the class has never been truly object oriented and relied heavily on the recordbuffer and the filelist. Not to say global indicator and variables. The class is also a pain to explain newcomers to vdf because some methods just doesn’t make sense for them. I will try to explain some of them in just a second.

    The request goes for a completely NEW DATADICTIONARY CLASS that I have chosen to call a DataDictionary2 class (DD2) in this Liberation Request. The idea is that the new DD2 class should give the VDF a true OOP class. I will layout the class later in this request.

    What’s wrong with the old DataDictionary class

    Why would I want a new DD2 class? Let me try to explain some of the problems that the old DD class have.

    First it relies heavily on the global recordbuffers. This is a big problem in many ways.
    Multiple DD Objects share the same global recordbuffer and they can come “out of sync” very easily. This can give some nasty side effects especially if you have some constraints in the DDO structures and they are very hard to track down while debugging your applications. Please have a look at a previous post I made on this particular issue.

    Finding data for the DD class are always done through the global recordbuffer. Try teaching freshly educated .NET programmers that within a days work And when you have found the data is is then duplicated to the local buffer of the DDO. And you can’t be sure that all data are copied from the recordbuffer to the local DDO buffer unless you have especially told it to do that. Saving of data are also done through the recordbuffer. So data are copied from the local DDO buffer to the global recordbuffer before a save is tried out.

    All the duplicated actions needed for the synchronisation like relate and attach are just time consuming and again very hard to comprehend for newcomer's. Well I still run into I-thought-I-had-understood-this-right situations from time to time.

    When do I access the recordbuffer and when do I access the DDO is another problem that I would like to eliminate the need to know and understand.

    Relations to other DDO’s are a “big field” too. They try to have something called a DDO_Server that relates the objects together, but it really doesn’t make any sence if you do not have an equal relate in the recordbuffers that the DDOs control. Second when you say that the DDO in one structure should constrain its legal dataset onbehalf of another DDO you do that indirectly by setting the Constrain_file property to (now hold on) a fileposition in the filelist. And it is up to the programmer to make sure that the DDO in question is actually controlling a recordbuffer of this file-number position via its Main_File property.

    Lock and the timeout event of incorrect master/alias settings are issues for the recordbuffer but when working with the DDO you just have to take that into account when setting up your database structure. So you need to pass information on master/alias- and file/field- relations before you start working with the DD. Even if you don’t use a specific DD class you can get into trouble in another DD class because that class has opened a connection to a recordbuffer that has yet to be told about the master/alias/file/field relations.

    Then there is the re-entry operation violations because the DataDictionary class is build on the DataSet (runtime class and probably yet again just a subclass of other abstract classes). That class is not able to run with different DataSet structures that operate independently of each other. If one operation is started in an DDO like a find operation no other DDO can do anything else during the operation. And that goes for the entire application regardless of how and where that DDO lives.

    The use of indicators like FOUND, FINDERR, Operation_mode, Operation_origin, the constraint test/found variables and so on are also something that you need to take special care about. You can’t trust them for a very long time and you need to store this information yourself if you need this for more that one command cycle worth of time. And one DDO interfere the results given from another DDO by this nature.

    Yes I know how the DD class came along during the history of (V)DF and that's why many of the above issues make sense if you know its history. It has had a very ruff childhood to grow up in, that's for sure. You tend to feel pity for it and you always make very care of how you treat it when you try to educate and tell the class how it should handle its data. Quite sure that I am not the only one that has been bitten quite often by the class if you just “assume things”. And if you have a distant cousin class that also “married” to the same recordbuffer you’ll better make sure those classes never gets to know about each other!

    I am sure that you can come up with many more examples where the OOP encapsulation went to the moon but this should highlight the main issues.

    DataDictionary2 class

    The idea is to have a new DD2 class that is not a subclass of the DD (or its superclasses) but a clean mean data machine class. It needs to be completely separated from the recordbuffer. We are talking total OOP isolation.

    Here are a layout of the new DataDictionary2 class.
    This is just an idea to illustrate what I had in mind about the DD2 class.

    I think that the DD2 class should be constructed of separated classes. Like a interface class for the Request messages and alike. A class for the business logic. A class for the table structure information. A class for Input/Output and a class to hold the data.

    All access to and from data should be done with an interface in the DD2 class and the DD2 has total control of its own data and the needed Input/Output operations. All data should be loaded directly from the database backend into the DD2 and save goes directly from the DD2 back to the database backend. Access to data should never be allowed without going through the Business Logic and I/O layer.

    Relations are set and respected between DD2 objects only. Do not use the filelist for that. Use only known relations from the database backend as a default for DD2 object relations if needed. It should be possible to change the relationships in an DD2O structure when needed in the application. Do not setup default relations in the DD2 classes! Relations can easily change between different DD2O structures in the same application. I don’t mind adding a DDO or two more “by hand” if i need information from ie. these parent DDOs.

    Complete DD2O structures should be able to function in a parent object of a cObject class. Do not assume that a DD2O structure always are located inside a db-aware container. The studio should also recognise any DD2O structure in a source. If needed a Meta tag that is use able for the studio could be an idea. It should however be better than the {DDOHost=True} / { ComponentType=BPClass } combination that can only be set for classes.

    The runtime should quiry the database backend for information of the table structure when creating an DD2O. Don’t ask the backend all the time for this information.

    There should be local properties to hold information for the global indicators and variables like Found and the alike mentioned earlier for each DD2O. Do not use any global indicators or variables.

    Data Entry Object will have to be able to work with both DDOs and DD2Os.

    The DD2 class should be available for Web applications as well as the old DD class.

    Make it possible to have a DD2O as a memory only table. This can be used as a temporary table. The new array and struct functions should make it possible.

    The DD2 should be embedded SQL enabled. Have the loader return a set of records, and the business rule applied after loading of data. Use the interface to move up and down in and out the set as normal table access.

    Keep the recordbuffer around for whatever purpose it can be used for as long at they are completely isolated form the DD2. They might be handy to use for searching data in a DD2 class like validating data. But then again you should be able to create a dynamic DD2O, running through some records, maybe updating some data and destroy the DD2O again without interfering with the parent DD2O.

    Because DD2Os are completely encapsulated, they can coexists with the old DDOs and its related recordbuffers. That makes it possible to slowly change the existing code to the new DD2 classes without breaking the old code.

    Some ideas for the DD2 future
    Should you be able to share a Data object between different DD2O? Maybe a method to store the current state of a DD2O so you can search other data, update or delete and the restore the state? Maybe a method to clone a DD2O? The last one might be a method to clone any VDF object with only the object ID and name as a difference?

    Anyway I hope I have you some ideas of what could be the greatest class in VDF. Really we do make applications that control the input and output of data in a database. That's pretty much it right? Sure we print it out or send it some how over the Internet in a probably fancy way but still. Its a database application. So we need to have a very good controller to sit between the application layer and the database backend. This should be the DataDictionary2 class

    Kind Regards

    Allan Kim Eriksen.


    Pictures are gone
    It seems that the illustration for this post has decayed over the years since I posted this request. Granted some improvements has been made to the DD class like alias DD class, and local relation ships but the main part of the request is still very much valid I believe. Hope you can get an idea of the layout without the illustration as I don't have them anymore.
    Last edited by Allan Greis Eriksen; 2-Nov-2017 at 06:05 AM. Reason: Illustration has been lost

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •