>> I've noticed a trend in the propel where problems that will occur in> insert-sql are not shown as errors/warnings during the phing build> phase. Is this just missing error handling or is there some other> reason?

Well if you mean that you don't see the errors until you run the'insert-sql' target, then yeah -- this is known. The SQL isn't actuallyrun against the database until you run 'insert-sql', so some things (likethe previous INDEX()) issue won't be caught until then.

However, there are some schema errors that should be caught before hand. >From the subject of the message, it sounds like the problem you'rereferring to (duplicate pkey) could/should be caught. There is a methodthat is run at the end of loading the schema (I believe inphing/PropelDataModelTask.php) that should throw exceptions on obviouserrors. We just need to add other tests in that method.

I've noticed a trend in the propel where problems that will occur in insert-sql are not shown as errors/warnings during the phing build phase. Is this just missing error handling or is there some other reason?

Thanks,

Matt

On Apr 12, 2004, at 15:42, Hans Lellelid wrote:

> Hi Matt & Denny,>> I applied the fix below to the foreignkey.tpl template. If you update> from CVS this should be there.>> I ended up using Matt's code w/o modification:>>> <?php foreach ($table->getForeignKeys() as $fk) { ?>>> INDEX (<?php echo $fk->getLocalCol​umnNames()?>),>> FOREIGN KEY (<?php echo $fk->getLocalCol​umnNames()?>) REFERENCES>> <?php echo $fk->getForeignTableName() ?> (<?php echo>> $fk->getForeignColumnNames() ?>),>> <?php } ?>>> since MySQL/InnoDB does not complain if you define an index more than> once. That made it easier than needing to check to see whether index> already existed -- and I wasn't completely sure what would happen if> column was part of another multi-column index, etc. We'll keep it like> this unless someone has trouble with it.>> Thanks,> Hans>> --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: users-unsubscribe@pr​opel.tigris.org> For additional commands, e-mail: users-help at propel dot tigris dot org>>

since MySQL/InnoDB does not complain if you define an index more thanonce. That made it easier than needing to check to see whether indexalready existed -- and I wasn't completely sure what would happen ifcolumn was part of another multi-column index, etc. We'll keep it likethis unless someone has trouble with it.

Thanks for the code sample. This is almost 100% right. The only thing weneed to check is whether the col was already specified (in the schama) asbeing indexed. I'll do this now & should have it ready for you to test ina few minutes.

No, I'm glad you sent the email! :) It just means that this needs to getfixed asap. What are you people doing using MySQL w/ foreign keys? :) I'll try to get that issue fixed today. I'll send a note to this listwhen I've fixed it. In the short-term, you can just tweak your generatedSQL files, adding the INDEX() for each fkey column.

This isn't a hard template fix, just need to make sure it takes intoconsideration possibility that a fkey column was already specified as anindex, etc.

Yes, I believe this is a known issue (and in the bug tracker for me totackle). I believe the error you got had something to do with lack ofindexes on the fkey constraints, correct? This seems to be amysql/innodb issue -- well, not an issue, just a difference betweenmysql and other dbs that use fkeys. This should be no problem to fix,since we have individual templates for all the db systems. I justhaven't done it yet:) I think there's even some code on the dev list.... I'll try to getthis done ASAP.

Yes, I believe this is a known issue (and in the bug tracker for me totackle). I believe the error you got had something to do with lack ofindexes on the fkey constraints, correct? This seems to be amysql/innodb issue -- well, not an issue, just a difference betweenmysql and other dbs that use fkeys. This should be no problem to fix,since we have individual templates for all the db systems. I justhaven't done it yet:) I think there's even some code on the dev list.... I'll try to getthis done ASAP.

Yes, I believe this is a known issue (and in the bug tracker for me totackle). I believe the error you got had something to do with lack ofindexes on the fkey constraints, correct? This seems to be a mysql/innodbissue -- well, not an issue, just a difference between mysql and other dbsthat use fkeys. This should be no problem to fix, since we haveindividual templates for all the db systems. I just haven't done it yet:) I think there's even some code on the dev list.... I'll try to getthis done ASAP.

The website update is still manual -- I just update the checkout in the docs/user_guide directory. It'd probably be good to eventually update this at some point, but for now I dont mind just jumping in there & updating it.

(BTW -- I did update it after your fix.)

Hans

Matthew B.Hershberger wrote:

> Hans,>> The typo has been fixed in cvs. When and/or how is the website updated?>> Thanks,>> Matt>> On Apr 9, 2004, at 10:20 AM, Hans Lellelid wrote:>>> Hi Matt-->>>>> I found a syntax error, a very trivial mistake, in the manual under >>> Many to Many relationships there is a missing `>' after `<table'. If >>> I check out the cvs can I update the manual as I find errors or >>> should I just report them via the mailing list?>>>>>> Absolutely feel free to fix any errors you find (in manual or >> elsewhere). It's also fine to submit bug reports, but in many cases >> it might be just faster to fix it yourself & commit. All we ask is >> that if you are fixing something that might break existing code >> (obviously doesn't apply to the manual), send out a note to >> dev at propel dot tigris dot org first to double check. But really -- a very >> relaxed policy on committing to CVS. It is, afterall, CVS and we can >> rollback if something breaks. Mostly we're just really grateful for >> any help & have no desire to make it difficult or beaurocratic for >> people to help out.>>>> I granted you 'developer' role on the project so that you can commit >> to the CVS repository.>>>> Thanks!>> Hans>>>>>>>> --------------------​--------------------​--------------------​--------->> To unsubscribe, e-mail: users-unsubscribe@pr​opel.tigris.org>> For additional commands, e-mail: users-help at propel dot tigris dot org>>>>>>> --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: users-unsubscribe@pr​opel.tigris.org> For additional commands, e-mail: users-help at propel dot tigris dot org>

The typo has been fixed in cvs. When and/or how is the website updated?

Thanks,

Matt

On Apr 9, 2004, at 10:20 AM, Hans Lellelid wrote:

> Hi Matt-->>> I found a syntax error, a very trivial mistake, in the manual under >> Many to Many relationships there is a missing `>' after `<table'. If >> I check out the cvs can I update the manual as I find errors or >> should I just report them via the mailing list?>> Absolutely feel free to fix any errors you find (in manual or > elsewhere). It's also fine to submit bug reports, but in many cases > it might be just faster to fix it yourself & commit. All we ask is > that if you are fixing something that might break existing code > (obviously doesn't apply to the manual), send out a note to > dev at propel dot tigris dot org first to double check. But really -- a very > relaxed policy on committing to CVS. It is, afterall, CVS and we can > rollback if something breaks. Mostly we're just really grateful for > any help & have no desire to make it difficult or beaurocratic for > people to help out.>> I granted you 'developer' role on the project so that you can commit > to the CVS repository.>> Thanks!> Hans>>>> --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: users-unsubscribe@pr​opel.tigris.org> For additional commands, e-mail: users-help at propel dot tigris dot org>>

> I found a syntax error, a very trivial mistake, in the manual under > Many to Many relationships there is a missing `>' after `<table'. If I > check out the cvs can I update the manual as I find errors or should I > just report them via the mailing list?

Absolutely feel free to fix any errors you find (in manual or elsewhere). It's also fine to submit bug reports, but in many cases it might be just faster to fix it yourself & commit. All we ask is that if you are fixing something that might break existing code (obviously doesn't apply to the manual), send out a note to dev at propel dot tigris dot org first to double check. But really -- a very relaxed policy on committing to CVS. It is, afterall, CVS and we can rollback if something breaks. Mostly we're just really grateful for any help & have no desire to make it difficult or beaurocratic for people to help out.

I granted you 'developer' role on the project so that you can commit to the CVS repository.

I found a syntax error, a very trivial mistake, in the manual under Many to Many relationships there is a missing `>' after `<table'. If I check out the cvs can I update the manual as I find errors or should I just report them via the mailing list?