Re: [Catalyst] Re: recommendation
Octavian Rasnita wrote:
This approach *is* best practice and it *does* work fine for
SQLite, MySQL and Postgres at least.
So far I can confirm this at least for MySQL.
I had a short look on PostgreSQL and noticed that there is no support
for ENUMs, neither directly (AFAIK ENUM is quite new for Pg) nor by a
CHECK constraint on varchar. But since I don't use Pg I actually don't
care much.
I've reported a very long time ago but nothing happend. But maybe I
am doing something wrong.
I remember the following types of errors (for MySQL 5):
The date field used to get a field size which is not correct, like:
mydate date(10)
Simply don't specify the size for date/datetime/tim fields.
Can be counted as a bug at least for MySQL and SQLite (Pg seems OK).
and the enum() field doesn't remember the field elements.
The field elements for enum field types are not saved in the DBIC
class file when the classes are created using the Catalyst helper.
So when the SQL string is re-created, it looks something like:
members enum()
which of course, gives an error when trying to update the database.
xyz = {
data_type = 'enum',
extra = {list = [qw(foo bar baz)]}
}
--
Bernhard Graf
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: recommendation
From: Bernhard Graf [EMAIL PROTECTED]
mydate date(10)
Simply don't specify the size for date/datetime/tim fields.
Can be counted as a bug at least for MySQL and SQLite (Pg seems OK).
and the enum() field doesn't remember the field elements.
The field elements for enum field types are not saved in the DBIC
class file when the classes are created using the Catalyst helper.
So when the SQL string is re-created, it looks something like:
members enum()
which of course, gives an error when trying to update the database.
xyz = {
data_type = 'enum',
extra = {list = [qw(foo bar baz)]}
}
--
Bernhard Graf
Aha, so actually you are saying that the DBIC::Schema Catalyst helper
doesn't create a complete and valid schema, and I must edit it manually.
But if I'll edit it manually, I would break the checksum.
I must say that I don't understand what is that checksum used for if the
recommended way is to use the Catalyst helper only once for creating the
DBIC schema, then alter the database from it.
Do I understand correctly that:
1. That checksum is useful for those who don't need to use special
components or settings in the class file and want to make changes in the
database then update the DBIC classes from the database using the Catalyst
helper.
2. That checksum has no value for those who need to use some components and
configuration that can't be done by the Catalyst helper, and they should use
the Catalyst helper only once (if they want) for creating the DBIC classes,
then they can make any changes they want in them, without needing to put
those changes below the checksum only, and without needing to use a BEGIN {}
block.
So they can make the necessary correction after creating the DBIC classes,
and then alter the database from those classes.
I was confused by the thing that a year or so ago there was no checksum
defined in the DBIC classes, but that constraint appeared recently, so I
thought that using the Catalyst helper for updating the DBIC classes was the
recommended way.
Thank you.
Octavian
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: recommendation
From: Bernhard Graf [EMAIL PROTECTED] Octavian Rasnita wrote: Aha, so actually you are saying that the DBIC::Schema Catalyst helper doesn't create a complete and valid schema, and I must edit it manually. That's my way ATM: 1. Data definition for MySQL in plain ASCII (because I'm used to it) 2. use the DBIC::Schema Catalyst helper to build the schema classes 3. overhaul the created schemas 4. write a tiny deploy script: Thank you for the examples. I think I will also follow this way, because I also start creating the data definition in plain ASCII. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: recommendation
On Mon, Nov 10, 2008 at 09:40:13PM +0200, Octavian Rasnita wrote: although it's not what you asked, i'll comment that i've had great luck doing this the other way round: i write the classes (with a lot of help from an emacs template*) and generate a DDL script from those. in addition to making table creation trivial, sqlt-diff produces scripts which (usually) do a fine job of upgrading from one version to another. see create_ddl_dir() here: http://tinyurl.com/5vgwcj and sqlt-diff here: http://tinyurl.com/6ql6wo for details. i'm much better at writing perl classes than DDL though, so it was obvious that this was the right thing for me in a 50 table, 10 view database. no doubt your mileage will vary. k. This could be also a good solution, but unfortunately it gives so many errors that it would be more simple to update the DBIC classes manually. I've just tried create_ddl_dir again to see if it works better now, but I needed to make more tens of corrections for a database with only 10 simple tables. This approach *is* best practice and it *does* work fine for SQLite, MySQL and Postgres at least. If you need to make tens of corrections, one of two things is happening: (1) you've found a bug and should have reported it but didn't (2) you did something wrong Either way, please get on the dbix-class list and report what code you have and we can tell you which it is. -deploy *is* best practice, it *does* work and it's going to be marked non-experimental for 08100. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: recommendation
From: Matt S Trout [EMAIL PROTECTED] On Mon, Nov 10, 2008 at 09:40:13PM +0200, Octavian Rasnita wrote: although it's not what you asked, i'll comment that i've had great luck doing this the other way round: i write the classes (with a lot of help from an emacs template*) and generate a DDL script from those. in addition to making table creation trivial, sqlt-diff produces scripts which (usually) do a fine job of upgrading from one version to another. see create_ddl_dir() here: http://tinyurl.com/5vgwcj and sqlt-diff here: http://tinyurl.com/6ql6wo for details. i'm much better at writing perl classes than DDL though, so it was obvious that this was the right thing for me in a 50 table, 10 view database. no doubt your mileage will vary. k. This could be also a good solution, but unfortunately it gives so many errors that it would be more simple to update the DBIC classes manually. I've just tried create_ddl_dir again to see if it works better now, but I needed to make more tens of corrections for a database with only 10 simple tables. This approach *is* best practice and it *does* work fine for SQLite, MySQL and Postgres at least. I am very glad to hear this. If you need to make tens of corrections, one of two things is happening: (1) you've found a bug and should have reported it but didn't I've reported a very long time ago but nothing happend. But maybe I am doing something wrong. I remember the following types of errors (for MySQL 5): The date field used to get a field size which is not correct, like: mydate date(10) and the enum() field doesn't remember the field elements. The field elements for enum field types are not saved in the DBIC class file when the classes are created using the Catalyst helper. So when the SQL string is re-created, it looks something like: members enum() which of course, gives an error when trying to update the database. (2) you did something wrong Either way, please get on the dbix-class list and report what code you have and we can tell you which it is. Ok, I will try to write again to DBIx::Class mailing list. I hope my messages will reach the list(s) because in the last few weeks, many messages are rejected from both DBIC and Catalyst mailing lists. -deploy *is* best practice, it *does* work and it's going to be marked non-experimental for 08100. Good news! Thank you. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: recommendation
From: kevin montuori [EMAIL PROTECTED] OR == Octavian Rasnita [EMAIL PROTECTED] writes: OR Especially for a beginner, but not only, the most simple way of OR creating the DBIC classes for a Catalyst app is to use the OR DBIC::Schema helper. although it's not what you asked, i'll comment that i've had great luck doing this the other way round: i write the classes (with a lot of help from an emacs template*) and generate a DDL script from those. in addition to making table creation trivial, sqlt-diff produces scripts which (usually) do a fine job of upgrading from one version to another. see create_ddl_dir() here: http://tinyurl.com/5vgwcj and sqlt-diff here: http://tinyurl.com/6ql6wo for details. i'm much better at writing perl classes than DDL though, so it was obvious that this was the right thing for me in a 50 table, 10 view database. no doubt your mileage will vary. k. This could be also a good solution, but unfortunately it gives so many errors that it would be more simple to update the DBIC classes manually. I've just tried create_ddl_dir again to see if it works better now, but I needed to make more tens of corrections for a database with only 10 simple tables. The main problem is that the DBIC class files as they are now, are harder to update automaticly. It would be nice if the information about tables and their columns would be kept in separate files than the rest of the code. In that way, the code could get the information about tables from those separate files (when using create=static) or even from the database when using create=dynamic. Such an interface would be much flexible, but I don't even know if it is possible to do it... Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
