2010-01-20 11 views
7

Attualmente stiamo introducendo DBIx::Class nel nostro team e vorremmo iniziare con DBIx::Class::Schema::Loader. Tuttavia, abbiamo requisiti rigidi sullo stile del codice, ad esempio, abbiamo Perl::Tidy come parte del nostro script pre-commit, poiché non abbiamo ancora ricevuto alcun codice generato. Ora, dovremmo assicurarci che il codice generato da Schema::Loader sia pulito e ordinato. Non è possibile eseguire perltidy sul codice prima del commit, dal momento che elimina l'hashing MD5 di DBIC. Quindi un post-processore integrato in Schema::Loader sarebbe il mio preferito e probabilmente l'unica soluzione fattibile. Ma ancora: come gestiresti questo problema?Come posso riordinare l'output di DBIx :: Class :: Schema :: Loader?

EDIT potrei pure rattoppare DBIx::Class::Schema::Loader::Base utilizzare un parametro perltidypreprocess se ottiene uno.

risposta

3

0.05000 è stato rilasciato (in precedenza la versione di sviluppo) ha l'opzione overwrite_modifications rbuels aggiunto.

Proverò ad aggiungere un'opzione post_process anche a breve.

3

La versione di sviluppo di DBICSL ora ha un'opzione overwrite_modifications che è possibile utilizzare per ignorare le modifiche nelle parti del codice md5summed. Questo dovrebbe consentire di eseguire perltidy sull'output prima di eseguirlo, ed essere ancora in grado di eseguire il re-dump in un secondo momento.

1

Questa domanda è stata posta qualche tempo fa, ma oggi ho dovuto occuparmene, quindi ho pensato di condividere la mia soluzione, in base alle modifiche apportate a questo modulo in quel momento. Se esegui la scansione dei documenti PerlTidy per --format-skipping, vedrai che puoi dare istruzioni PerlTidy su quale codice non debba essere riordinato. I marcatori di inizio e di fine sono # < < < e # >>> rispettivamente. Quindi, le impostazioni predefinite sarebbero simili a questa:

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

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

# start to tidy again 
#>>> 

$foo .= 'stuff'; 

Questo è abbastanza facile. Ora devi solo avere il Loader per avvolgere il codice generato con questi marcatori. Questo potrebbe essere simile a questa:

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]); 

La parte importante è filter_generated_code, che permette di avvolgere il codice generato. Ora puoi generare i tuoi file di schema e ancora PerlTidy loro. Ciò ti consentirà di riordinare il codice personalizzato che aggiungi nella parte inferiore dei file generati senza incorrere negli errori che si verificano quando il codice generato viene alterato da qualcosa di diverso da make_schema_at().

Nel mio caso, ho deciso di disattivare generate_pod, perché PerlTidy era ancora (per qualche motivo) inserendo alcune newline nel Pod generato. Non ho ancora capito perché sia ​​così, ma spegnere il Pod lo corregge e posso vivere senza di esso.

Problemi correlati