angel-dart / angel

[ARCHIVED] A polished, production-ready backend framework in Dart for the VM, AOT, and Flutter.
https://angel-dart.dev/
MIT License
1.06k stars 67 forks source link

Migrations do not work within applications deployet as snapshots #220

Closed thosakwe closed 3 years ago

thosakwe commented 4 years ago

This issue was originally created by @vadimtsushko here, before being automatically moved: https://github.com/angel-dart-archive/orm/issues/83


Hi Tobe, I've just started switching to your ORM in some of my new projects, so far so good. API is quite nice, generally working with it pretty enjoable (admittedly I use it only in simple scenarios yet). I have small problem though. In my case ORM is embedded in small CLI application, that is deployed as dart snapshot file with dart executable. This applications has several commands delegating actual job to migration_runner. So when deployed to snapshot migration up command breaks on the line https://github.com/angel-dart/orm/blob/76016f20624621738748daeec38a3d4407184270/angel_migration_runner/lib/src/util.dart#L13 because with snapshots we do not have any package layout and so on (that's one of the main reasons of using snapshots anyway) For now I've currently just added a conditional branch for null source file path, using Class name as a name of migration in that case. I'm not sure that is ideal solution though so I didn't make a PR. Another, related point is - using dart:mirrors just once in whole ORM effectively prevents us from using new AOT snapshots in deployed applications. Snapshot generation breaks with error about dart:mirrors. I believe ideally we shouldn't use mirrors anymore, they tends to be more and more a liability in all sorts of different scenarios

thosakwe commented 4 years ago

@thosakwe commented:

Apologies for the late response.

A possible solution is maybe including that information in the generated migration class. It's pretty feasible:

class MyMigration extends Migration {
  @override
  String get sourceHash => 'package:foo/lib/src/models.dart#_MyClass';
}

The only thing is that this would be a breaking change for existing migrations. Perhaps a fallback could use package:stack_trace and some other hackery to figure out the class name:

// pseudocode:
String get sourceHash {
  String file, className;
  var trace = Trace.current();
  file = trace.frames.first.filename;
  className = runtimeType.toString();
  return file + '#' + className;
}