Tabellen anlegen lassen über TDatabaseManager

[marcibaer]

Hallo zusammen,

nachdem ich der Zugriff auf die Datenbank hinbekommen habe, habe ich nun versucht, die Tabellen automatisch generieren zu lassen, was aber nicht funktioniert. die DB bleibt leer ...
GetEntities() inTDatabaseManager.Create liefert eine leere Liste zurück, obwohl ich ja 2 Entities definiert habe!

Die Tabellen sehen dabei wie folgt aus (nur zu Testzwecken):

Delphi-Quellcode:

  [Entity]
  [Table('Customers')]
  TCustomer = class
  private
    [Column('CUSTID', [cpRequired, cpPrimaryKey])][AutoGenerated]
    FId: Integer;
    //[OneToMany(false, [ckCascadeAll])]
    FName: string;
    FAge: Integer;
    FLastEdited: TDateTime;
    FEmail: string;
  public
    property ID: Integer read FId;
    [Column] property Name: string read FName write FName;
    [Column('Age',[],3,0)] property Age: Integer read FAge write FAge;
    [Column] property LastEdited: TDateTime read FLastEdited write FLastEdited;
    [Column('Mail',[],50)] property EMail: string read FEmail write FEmail;
  end;

  [Entity]
  [Table('Orders')]
  TOrder = class
  private
    [Column('ORDID', [cpRequired, cpPrimaryKey])][AutoGenerated]
    FId: Integer;
    [Column('CUSTID', [cpRequired, cpNotNull])]
    FCustomerId: Integer;
    //[ForeignJoinColumn('CUSTID','Customers','FId',[fsOnDeleteCascade])]
    FOrderDate: TDate;
  public
    property ID: Integer read FId;
    property CustomerId: Integer read FCustomerId write FCustomerId;
    [Column] property OrderDate: TDate read FOrderDate write FOrderDate;
  end;

Angelegt werden soll das Ganze folgendermaßen:

Delphi-Quellcode:

var
  Connection: TZConnection;
  Adapter: IDBConnection;
  Session: TSession;
  LDBManager: TDatabaseManager;
begin
  Connection := TZConnection.Create(nil);
  with Connection do
    begin
      Port := 1224;
      HostName := '1.2.3.4';
      User := 'Ich';
      Password := 'Keins';
      Database := 'MyDB';
      Protocol := 'mysql';
    end;
  Adapter := TZeosConnectionAdapter.Create(Connection);
  with Adapter do
    begin
      QueryLanguage := qlMySQL;
      Connect;
    end;
  LDBManager := TDatabaseManager.Create(Adapter);
  try
    LDBManager.BuildDatabase;
  finally
    LDBManager.Free;
  end;

Zusätzliche Frage: sind die beiden auskommentierten Attribute korrekt und an der richtigen Stelle, um einen Foreign Key zu setzen?

Vielen Dank für Eure Hilfe,

Marc

[RSF]

Warum nicht einfach per SQL Skript eine neue Tabelle anlegen

[marcibaer]

Mache ich auch ... ist allerdings doppelter Aufwand ...
Schöner wäre es doch, wenn ich Tabellen einmal im Quellcode "anlege" und diese dann erzeugt würden.

Viele Grüße,

Marc

[p80286]

Zitat von marcibaer:

Mache ich auch ... ist allerdings doppelter Aufwand ...

Im allg. werden die Tabellen einer DB einmal angelegt und gut ist.
(Es können natürlich Korrekturen notwendig sein aber das macht man eigentlich auch nur einmal!)

Gruß
K-H

[jobo]

"Einmal" ist ja nur bedingt der Fall. Ein Programm, das dem Nutzer die Verwaltung der kommenden WM Ergebnisse nebst Tippprognosen, persönlicher Spielerbewertung etc erlaubt, wird vielfach installiert inkl. DB, zumindest bei lokaler Datenhaltung.
Das kann man auf die "klassische" Art machen, per Skript oder halt mit einem Persistenzsystem.
Das ist beides möglich und erlaubt.

Hier sieht es so aus, als ob es um ein Persistenzsystem geht und ein Fehler im Code vorliegt.

[p80286]

Zitat von jobo:

Das ist beides möglich und erlaubt.

Geschenkt, aber was spricht gegen ein - extern testbares - Script, was mit Hilfe von execsql( oder war es SQLexec?) auf die DB losgelassen wird?
Wenn ich mich recht erinnere muß der TDatabaseManager mit ähnlichen Parametern gefüttert werden, die man auch in dem Script finden würde, nur scheint es da irgendwo zu klemmen, was in meinen Augen nicht unbedingt für diese Komponente bzw. ihre Dokumentation spricht.

Gruß
K-H

[jobo]

Zitat von p80286:

Zitat von jobo:

Das ist beides möglich und erlaubt.

Geschenkt, aber was spricht gegen ein - extern testbares - Script, was mit Hilfe von execsql( oder war es SQLexec?) auf die DB losgelassen wird?
Wenn ich mich recht erinnere muß der TDatabaseManager mit ähnlichen Parametern gefüttert werden, die man auch in dem Script finden würde, nur scheint es da irgendwo zu klemmen, was in meinen Augen nicht unbedingt für diese Komponente bzw. ihre Dokumentation spricht.

Nichts, aber dann nutzt man ja nur die Hälfte des Systems. Also entweder Script gesteuert oder ein Persistenzsystem. Ich würde es zumindest nur so einsetzen.

Und wenn hier mal ein Thread auftaucht, wo es klemmt, heißt das ja noch nicht viel. Das ganze Forum besteht aus solchen Threads. Wenn sich jemand findet, der weiß wie es geht, ist es halt erledigt. Mglw. ist die Komponente auch tatsächlich Schrott, das spricht aber nicht gegen die gewollte Strategie, finde ich.

[Schokohase]

Zitat von p80286:

Geschenkt, aber was spricht gegen ein - extern testbares - Script, was mit Hilfe von execsql( oder war es SQLexec?) auf die DB losgelassen wird?
Wenn ich mich recht erinnere muß der TDatabaseManager mit ähnlichen Parametern gefüttert werden, die man auch in dem Script finden würde, nur scheint es da irgendwo zu klemmen, was in meinen Augen nicht unbedingt für diese Komponente bzw. ihre Dokumentation spricht.

Da stellen einige Leute unentgeltlich Sachen der Allgemeinheit zur Verfügung und der Dank dafür ist Bashing?

Zumal die Lösung recht simpel und erst einmal nichts mit dem TDatabaseManager zu tun hat, sondern damit, das der Linker ungenutzte Typen einfach nicht in das Kompilat lässt und diese zur Laufzeit nicht gefunden werden können.

Einfach die Typen verwenden, dann werden die auch gefunden.

[jobo]

Zitat von Schokohase:

Da stellen einige Leute unentgeltlich Sachen der Allgemeinheit zur Verfügung und der Dank dafür ist Bashing?

Zumal die Lösung recht simpel und erst einmal nichts mit dem TDatabaseManager zu tun hat, sondern damit, das der Linker ungenutzte Typen einfach nicht in das Kompilat lässt und diese zur Laufzeit nicht gefunden werden können.

Einfach die Typen verwenden, dann werden die auch gefunden.

Ich denke, dass die Beiträge hier nicht als Bashing gemeint waren.
Ich hätte jetzt eher gehofft, dass die Spring4d Spezialisten (oder besser der Spezialist: Stevie?) sich mal melden.

Aber Dein Tipp macht ja auch Sinn, vielleicht probiert Marc das einfach mal aus und meldet sich mit den Resultaten. Und evtl dreht er mal am Exception Handling, um festzustellen, was beim genau BuildDatabase schief geht.

[TigerLilly]

Zitat:

Ich hätte jetzt eher gehofft, dass die Spring4d Spezialisten (oder besser der Spezialist: Stevie?) sich mal melden.

Hier wirst du eher sinnvolle Antworten auf deine Frage erhalten:
https://groups.google.com/forum/#!forum/spring4d