Makes sense. IMHO most of the stuff I mentioned is just minor qualms. The overall syntax is pretty nice, and I think it'd be a great idea to have something like this.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Sun, Aug 19, 2012 at 7:12 AM, Daniel Friesen <dan...@nadir-seen-fire.com>wrote: > On 12-08-18 10:37 PM, Tyler Romeo wrote: > > I think this is an awesome idea and I'd be willing to help on this. > > I have a few questions about the page linked above though: > > - Why don't we use foreign keys in MySQL? > > We don't use them now so I didn't use them in the abstract table schema > types. PostreSQL and iirc Oracle use them so I added reference(), it also > acts as a documentation hint. We could regenerate the table schema > documentation based on this. This time around directly extracting what > column refers to another out of the code. > For MySQL, FKeys actually lower performance, but in any case if you think > we should use foreign keys we should have a wikitech-l discussion over it. > > > > - The word "hack" is used three times. That's probably an issue. ;) > > Heh. Yeah. Though how else do we handle the few spots where a part of > our database schema goes and does something complete out of line from the > rest of the schema? > eg: cl_timestamp uses timestamp instead of our binary(14). > > > > - Is there a reason we're changing the default from NULL to NOT NULL? > Wouldn't it be better to just use a "required" keyword? > > 95% of our column definitions are NOT NULL. In fact not allowing null is > practically a default, you don't really allow null unless you make an > explicit decision that you want null values. > So I made NOT NULL the default and made allowing null an explicit nullable > flag. > NOT NULL only prevents you from setting a field as null. It doesn't make > it required because most other fields will still default to something like > 0, '', or some other default that's specified. So "required" doesn't really > fit the meaning > > > > - We should probably support MySQL's -- comment syntax, just in case. > > Yeah I planned to from the start. Just include opening #, --, and // > comments inside the parser. > Although, when it came to table alters I started contemplating the -- > comment vs. -column; parsing and rethought that. > Though thinking about it again, the parsing will probably work fine. > > > > - What's the [ignore] on the insert call do? (It becomes a little > confusing since there is also the [tablename] syntax on global indexes.) > > That was for INSERT IGNORE. After I noticed that some of our > archive/*.sql files use INSERT IGNORE. I dropped the idea of `insert ignore > tablename ...` because it would be ambiguous for a table named "ignore". > So yeah, it would be nice to find a better syntax for insert ignore. > I'm also contemplating if I should find a syntax for INSERT..SELECT since > we seem to use it in a small number of migrations. > > > > - The Alter Table syntax looks really weird (with tildas and whatnot). > > I started wanting to keep the alter table syntax as close as possible to > the table definition/creation syntax. > So I started with prefixing with - and + which work beautifully as DROP > and ADD column/etc... commands. > Then when I thought of MODIFY/CHANGE I didn't want to make that unprefixed > and ~ seemed to work best for that. > > But yeah, here and there it could use some ideas for alternative ways to > do the syntax. > > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] > > *--* > *Tyler Romeo* > Stevens Institute of Technology, Class of 2015 > Major in Computer Science > www.whizkidztech.com | tylerro...@gmail.com > > > > On Sat, Aug 18, 2012 at 2:20 PM, Daniel Friesen <li...@nadir-seen-fire.com > > wrote: > >> I see the branch, but I don't see the code: >> >> https://svn.wikimedia.org/viewvc/mediawiki/branches/abstract-schema/phase3/ >> It looks like someone just copied phase3 and then never actually changed >> any code. I don't even see a syntax idea there. >> >> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] >> >> On 12-08-18 11:10 AM, Chad wrote: >> > >> > We tried this before, and I'd love to see it happen. Take a look at >> > the abstract-schema branch in SVN for what we did. >> > >> > -Chad >> > >> > On Aug 18, 2012 1:53 PM, "Daniel Friesen" <li...@nadir-seen-fire.com >> > <mailto:li...@nadir-seen-fire.com>> wrote: >> > >> > We've got a nice abstract query system but our table creation and >> > migrations are horrible. We re-write them for multiple database >> > engines. And as a result extensions need to do the same and often >> > don't. Leading to things being a mess for databases other than >> MySQL. >> > >> > While I was doing the sites stuff a syntax for defining tables >> > came to mind and I wrote out an RfC for a method of defining our >> > database abstractly. >> > >> > >> https://www.mediawiki.org/wiki/Requests_for_comment/Abstract_table_definitions >> > >> > -- >> > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) >> > [http://daniel.friesen.name] >> > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
