Page 2 of 2 FirstFirst 1 2
Results 16 to 21 of 21

Thread: Hoe kan ik de Primary Key wijzigen op de Client dataset.

  1. #16
    Senior Member
    Join Date
    Jul 2008
    Location
    Ertvelde, Belgi?½
    Posts
    158
    Erwin,

    Client side heb ik in mijn test applicatie een TDSRestConnection. Client side heeft de applicatie totaal geen weet van DataBase zaken. Client Side wordt de TFDMemTable opgevuld met data, die via een call naar een method op de REST DataSnap Server, wordt opgehaald :

    Delphi Code:
    1. var
    2.   oListData      : TFDJSONDataSets;
    3. begin
    4. //  fdstpTest.Open;
    5.   if ( mtblTest.Active )  then
    6.   begin
    7.     mtblTest.Close;
    8.   end;
    9.  
    10.   oListData      := DSCustomerClient.GetListData;
    11.   try
    12.     mtblTest.AppendData( TFDJSONDataSetsReader.GetListValue( oListData, 0 ) );
    13.     mtblTest.Open;
    14.   finally
    15.     if ( Not InstanceOwner ) then
    16.     begin
    17.       FreeAndNil( oListData );
    18.     end;
    19.   end;
    20. end;

    Bij een ApplyUpdates op die Client Side TFDMemTable wordt dan weer een method uitgevoerd die ervoor zorgt dat de data naar de Rest DataSnap server gestuurd wordt en daar het nodige gebeurt :

    Delphi Code:
    1. procedure TClientModule1.ApplyUpdatesNew;
    2. var
    3.   aDataSet   : TFDMemTable;
    4.   oDeltas    : TFDJSONDeltas;
    5.   aError     : string;
    6.   aField     : TField;
    7.   aReader    : TFDJSONDataSetsReader;
    8. begin
    9.   aDataSet := mtblTest;
    10.  
    11.   // Make sure we save the changes to the DataSet first.
    12.   if ( aDataSet.State in dsEditModes ) then
    13.   begin
    14.     aDataSet.Post;
    15.   end;
    16.  
    17.   oDeltas   := TFDJSONDeltas.Create;
    18.   try
    19.     TFDJSONDeltasWriter.ListAdd( oDeltas, 'DETAIL', aDataSet );
    20.  
    21.     aError := DSCustomerClient.UpdateListData( oDeltas );
    22.  
    23.     if ( aError <> '' ) then
    24.     begin
    25.       raise Exception.CreateFmt( '$s - %s', [ Self.ClassName, aError ] );
    26.  
    27.     end;
    28.   end;
    29. end;

    Properties aanpassen op de TFDMemTable client side heeft dus weinig zijn, want die staat volledig los van de Rest DataSnap server en dus ook de achterliggende data.

  2. #17
    hmmm als je nu op de laatste BeDelphi had opgelet had je allang met kbmMW gewerkt natuurlijk

    Maar even zonder dollen, ik zou denk ik in jullie wens scenario even nadenken over een iets andere architectuur. Resolven e.d. kun je volgens mij houden zoals je het nu al doet op de server. Maar ik zou dan vervolgens een broadcast doen van de wijzigingen zodat alle clients op de hoogte zijn en hun records kunnen aanpassen. Omdat je het resolven (ik gebruik de kbmMW term, bij datasnap is het apply updates en in jullie framework heet het mogelijk anders) centraal doet op je server hou je dus controle over aanpassingen in de DB.

    Bij toevoegen door een enkele client moet je dan denk ik wel even opletten. Die betreffende client heeft namelijk een record zonder ID dat aangepast moet worden. Alle andere clients zullen dat record toe moeten voegen. Updates zijn makkelijk, omdat je dan al een PK hebt die gevuld is.

    kbmMW heeft zijn eigen messaging systeem, waaronder ook pub sub messaging. Maar er zijn ook prima alternatieven, je zou bv een rabbitMQ server in je server landschap kunnen opnemen. Je dataserver is een client van rabbitMQ en published de wijzigingen. RabbitMQ zorgt vervolgens dat dat bericht aankomt op de clients die een subscription hebben. Daar kun je dan met een event de lokale storage bijwerken.

    Ik zou bij bv rabbitMQ verder kiezen voor een gangbaar protocol zoals AMQP (veel gebruikt) of MQTT (recent steeds populairder, maar alleen hele kleine datapackets). Er zijn ook clientlib's beschikbaar voor Delphi, en voor veel andere talen. Door te gaan voor zo'n standaard protocol kun je in de toekomst ook veel makkelijker niet delphi zaken knopen aan je delphi server.

    Voordeel van de messaging is dat het async is en je in de meeste gevallen gewoon op een event kunt inhaken.
    Last edited by Benno; 09-Apr-18 at 16:30. Reason: typo + aanvulling updates

  3. #18
    Senior Member
    Join Date
    Jul 2008
    Location
    Ertvelde, Belgi?½
    Posts
    158
    Wel Benno ... had je tijdens mijn laatste BeDelphi presentatie opgelet, dan had je geweten dat ik geen fan ben van veel buzzwords en extra afhankelijkheden die eigenlijk niets bijbrengen tot het probleem.

    Maar goed ... even zonder dollen. Wij hadden het liefst zo weinig mogelijk externe frameworks gebruiken en vertrouwd op de DataSnap / FireDAC manier van werken. We hebben nog een paar andere alternatieven die we momenteel bekijken zoals het DelphiMVCFrameWork. Dat laatste zou ons immers toelaten om een deftige REST server te hebben die we ook via andere tools kunnen aanspreken natuurlijk. De standaard DataSnap / FireDAC was mooi geweest, maar blijkbaar had ik er misschien iets te veel van verwacht.

  4. #19
    Dat laatste zou ons immers toelaten om een deftige REST server te hebben die we ook via andere tools kunnen aanspreken natuurlijk.
    Ik weet niet of je daar perse een MVC framework voor nodig hebt.

    Ik ben zelf nooit fan geweest van de datasnap aanpak, doordat je al snel verweven code krijgt tussen server en client en het door dat sessie geneuzel ook lastig is om de boel schaalbaar en beheersbaar te houden.

    Je business case los je overigens volgens mij niet op met een dikke rest server. Je hebt dan namelijk nog steeds het probleem dat je clients niet weten dat ze hun data moeten updaten. Uiteraard kun je je clients om de x tijd laten pollen naar je restserver om eventuele wijzigingen op te halen, maar dat blijft een relatief dure oplossing natuurlijk die je eigenlijk niet wilt.

    Ik las eerder dat jullie Firebird gebruiken. Mogelijk is het een optie om iets met triggers te doen in de database, die vervolgens een event triggeren waar je app server op kan reageren. Maar ook dat is een beetje een gekunstelde constructie en mijn ervaring is dat business logica in de database (triggers, sp's e.d.) al heel snel gaat lijden tot een onbeheersbaar geheel.

  5. #20
    Christophe
    Join Date
    Jan 2004
    Location
    Belgium, West-Vlaanderen, Nieuwkerke
    Posts
    459
    Je hebt dan namelijk nog steeds het probleem dat je clients niet weten dat ze hun data moeten updaten
    Volgens mij moeten de andere clients niet weten of er een update is van een bepaalde record. Ik denk dat dit overkill is.
    Als de client bv een persoon opvraagt met id 1 dan krijgt de client deze persoon. De gebruiker wijzigt de data van persoon (1) en dan saved hij de Data.
    Dan worden de update data naar server gestuurd voor een update (Validatie, rules...) met eventueel een response naar de client (Ok/errors). Dan moet toch geen andere client weten dat persoon (1) gewijzigd is.

  6. #21
    Volgens mij moeten de andere clients niet weten of er een update is van een bepaalde record. Ik denk dat dit overkill is.
    Ok. Dat was dan een foute aanname van me. Ik dacht dat te kunnen concluderen aan de hand van het verhaal van Stefaan. In dat geval hoef je dan ook niet moeilijk te gaan doen met een messaging framework om de updates rond te sturen.

Page 2 of 2 FirstFirst 1 2

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

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