On Thu, 2010-03-18 at 15:00 -0400, James Manning wrote: > · Database is “flipshare.db”, created by FlipShare 5.0 > software
Any chance you could provide a copy of this database. It would make testing and debugging easier. > After running DbMetal on the database… > > .\DBMetal.exe --pluralize --with-sql-dialect=SQLite > "--with-dbconnection=System.Data.SQLite.SQLiteConnection, > System.Data.SQLite, Version=1.0.61.0, Culture=neutral, > PublicKeyToken=db937bc2d44ff139" --namespace:FlipShareOM > --provider:SQLite "--conn:Data Source=C:\users\james\Videos\FlipShare > Data\flipshare.db" --code:FlipShareDataContext.cs You don't need --with-sql-dialect. The --with-sql-dialect option is for specifying an IVendor implementation, and SQLite isn't a valid type reference for an IVendor implementation... > … and modifying the query a little, I first noticed the PK’s came > through as int? instead of int, which seemed odd (based on looking at > the database through SQLite Maestro, my guess would be that the code > needs to look for not null || PK instead of just not null). Alas, not true; from http://www.sqlite.org/lang_createtable.html: The PRIMARY KEY attribute normally creates a UNIQUE index on the column or columns that are specified as the PRIMARY KEY. The only exception to this behavior is special INTEGER PRIMARY KEY column, described below. According to the SQL standard, PRIMARY KEY should imply NOT NULL. Unfortunately, due to a long-standing coding oversight, this is not the case in SQLite. SQLite allows NULL values in a PRIMARY KEY column. Emphasis mine. So yes, it would make sense that primary keys couldn't be null, but as per the SQLite docs, this is possible; thus int? is the correct type. (Unfortunately, I can't actually create a row with a NULL primary key value, so this may have been "fixed" since these docs were written; be that as it may, this is documented behavior, and we should abide by it.) ... > In DbLinq, I’m hitting this error when it tries the join between the > int?/integer PK and string/varchar(256). ... > However, that just moves the break to later when it’s trying to > compare a string and int: > You can't just avoid the types, as within the DbLinq core all types are checked. (Not strictly true, but as the DbLinq core uses System.Linq.Expressions, and System.Linq.Expressions does check, DbLinq in turn requires full typing.) So, the original failed because you weren't selecting on a column, and your hack fails because you're dropping type information. The "correct" solution is remove the requirement that leftTable be a TableExpression or ColumnExpression (as is currently required, and I have no idea how difficult that would be), as this would allow the types to match (as is required by Expression.Equal()). Given that a leftTable is required, you could probably just do a depth-first traversal of leftExpression looking for the first TableExpression or ColumnExpression you encounter and use that... - Jon -- You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/dblinq?hl=en.
<<attachment: image005.png>>
