Inoffizielles deutsches Xbase-Forum

1. Fehlende Xbase++ Programmierer-Kapazität
2. Zeitdruck
3. Ändernde Anforderungen
4. Prototyp-Entwicklungen durch nicht-Xbase++ Programmierer
   ...

1. Die Anwendungen benutzen dann schon zumindest teilweise REST-Technologie, was eine spätere Umzug auf Geschäftslogik-basierte APIs wenn vorhanden begünstigt.
2. Die potentielle Probleme mit kurzzeitig inkonsistente Indexen werden vermieden.
3. Einige ISAM-implementationsspezifische Details (wie Locking oder Versionierung) können standardmäßig behandelt werden, solange es nur jeweils um einen einzelnen Datensatz geht.
   ...

GET url/tablename/recno		GET würde ich zumindest in der ersten Implemention weglassen. Insbesondere die ?-Variante 
GET url/tablename?...		wäre schwer zu definieren und kann kaum mit der Macht eines SQL SELECTs mithalten.
POST url/tablename		Anstatt SQL INSERT
PATCH url/tablename/recno	Anstatt SQL UPDATE
DELETE url/tablename/recno	Als Xbase++ DELETE implementiert

{
    "ErrorCode" : 0,
    "ErrorMessage" : "",
    "TableName" : "",
    "RecNo" : 0,
    "RowVersion" : 0,
    "Fields" :
    {
        F1 : 0,
        F2 : "",
        ...
    }
}

• ErrorCode: Ist wahrscheinlich überflüssig, vermutlich sollte stattdessen der HTTP Fehlercode benutzt werden.
  Allerdings sollten spezifische Werte zurückgegeben werden für Fälle wie: TableName existiert nicht; Datensatz existiert nicht bzw. wurde gelöscht; RLOCK() für Datensatz scheitert; RowVersion stimmt nicht überein (sollte übrigens auch KeyVersion geprüft werden?); Feld existiert nicht; Feldinhalt vom falschen Typ (konnte nicht konvertiert werden);...
  Dazu kommen bestimmt einige mehr, potentiell auch anwendungsspezifische.
• ErrorMessage: Auf Englisch als Hilfe für den Programmierer bzw. mit zusätlichen Details, z.B. welche Felder fehlerhaft sind und warum.
• TableName: Der Tabellenname so wie in der Postgres Datenbank.
• RecNo: Entspricht RECNO() in Xbase++ bzw __record im SQL SELECT.
• RowVersion: Der zu erwartende/prüfende Wert von __rowversion bei POST und PATCH bzw. der aktuelle/resultierende Wert im Response.
  Es ist mir noch unklar, ob vielleicht auch __keyversion geprüft werden soll.
  Es werden übrigens über diese Schnittstelle keine bleibende Locks gesetzt.
• Fields: Für POST und PATCH, nur die Felder, die gesetzt werden sollten (auch im Response).
  Für Response zu DELETE (und GET falls implementiert), alle Felder im Datensatz.
  Der Microservice muss in beiden Richtungen Typkonvertierungen (entsprechend Feldname) für die Feldwerte machen.

wir wollen genau so eine generische Implementierung als Beispiel in der Version 3.0 haben

Ich suche mal in meinen Archiven nach der ersten Ankündigung von Xbase++ 3.0.

Tom hat geschrieben: ↑Mi, 22. Mär 2023 13:02 (Nichts für ungut. Die Jahre, die nach der ersten Ankündigung bis zur ersten halbwegs nutzbaren Version der PGDBE vergingen, lassen sich leichter in Generationen zählen. Es ist schön, dass Ihr das auch machen wollt. Aber, bei allem Respekt und bei aller Bewunderung - Eure Zeitplanung ist aus der Hölle. )

Frank Grossheinrich hat geschrieben: ↑Fr, 24. Mär 2023 13:42 Es hat mich in den Fingern gejuckt ... und eventuell völlig unpassend ...

XPP30.JPG


Das ist kein gebasteltes Bild, sondern ich installiere es mir gerade.
Und werde gleich danach mit den MicroServices "spielen", die schon nutzbar sind.
Und Vieles mehr.

Schöne Grüße
Frank

https://portal.alaska-software.com/