2010-01-20 15 views
7

Aktualnie przedstawiamy DBIx::Class w naszym zespole i chcielibyśmy rozpocząć od DBIx::Class::Schema::Loader. Mamy jednak twarde wymagania dotyczące stylu kodu, tj. Mamy Perl::Tidy jako część naszego skryptu pre-commit, ponieważ wcześniej nie mieliśmy wygenerowanego kodu. Teraz musimy upewnić się, że kod generowany przez Schema::Loader jest czysty i uporządkowany. Nie możemy uruchomić perltidy nad kodem przed zatwierdzeniem, ponieważ wkrada on skrót MD5 bazy danych DBIC. Dlatego post-procesor zintegrowany z Schema::Loader byłby moim preferowanym i prawdopodobnie jedynym możliwym rozwiązaniem. Ale wciąż: jak poradzisz sobie z tym problemem?Jak mogę uporządkować DBIx :: Class :: Schema :: Loader's output?

EDIT równie dobrze mogę załatać DBIx::Class::Schema::Loader::Base użyć parametru perltidypreprocess jeśli robi się jeden.

Odpowiedz

3

0.05000 został wydany (poprzednio wersja rozwojowa) ma opcję overwrite_modifications dodaną rbuels.

Postaram się też wkrótce dodać opcję post_process.

3

Wersja rozwojowa DBICSL ma teraz opcję overwrite_modifications, której można użyć do zignorowania zmian w części md5 pobranej z kodu. Powinno to pozwolić na uruchomienie perltidy na wyjściu przed jego zatwierdzeniem, a nadal będzie możliwe ponowne zrzucenie później.

1

To pytanie zostało zadane przed chwilą, ale musiałem sobie z tym dzisiaj poradzić, więc pomyślałem, że podzielę się moim rozwiązaniem, na podstawie zmian wprowadzonych do tego modułu w chwili obecnej. Jeśli zeskanujesz dokumenty PerlTidy dla pominięcia formatu, zobaczysz, że możesz podać instrukcje PerlTidy o tym, który kod nie powinien być uporządkowany. Znaczniki początkowe i końcowe to odpowiednio: # < < < i # >>>. Domyślne ustawienia wyglądają mniej więcej tak:

# tidy my code 
my $foo = 'bar'; 

#<<< 
# don't tidy the code below 
my $baz =  'foo'; 

# start to tidy again 
#>>> 

$foo .= 'stuff'; 

To proste. Teraz wystarczy, aby Loader owinął wygenerowany kod tymi znacznikami. To mogłoby wyglądać tak:

my %args = (                      
    components   => [ 'InflateColumn::DateTime', 'TimeStamp' ],             
    debug     => 1,                 
    dump_directory  => './lib',                
    filter_generated_code => sub {                
     my ($type, $class, $text) = @_;               
     return "#<<<\n$text#>>>";                 
    },                       
    generate_pod   => 0,                 
    naming     => 'current',               
    overwrite_modifications => 0,                 
    skip_load_external  => 1,                 
    use_moose    => 1,                 
    use_namespaces   => 1,                 
);                        

make_schema_at('My::Schema', \%args, [$dsn, $user, $pass]); 

Ważną częścią jest filter_generated_code, co pozwala owinąć wygenerowany kod. Teraz możesz generować pliki schematów i nadal je PerlTidy. Umożliwi to uporządkowanie niestandardowego kodu dodawanego na dole wygenerowanych plików bez uruchamiania błędów, które wystąpią, gdy wygenerowany kod zostanie zmieniony przez coś innego niż make_schema_at().

W moim przypadku postanowiłem wyłączyć generate_pod, ponieważ PerlTidy wciąż (z jakiegoś powodu) wstawiał nowe linie do wygenerowanej kapsuły. Nie do końca zrozumiałem, dlaczego tak jest, ale wyłączenie Poda rozwiązuje to i mogę bez niego żyć.