- [13:15] <airox> How is the new DQL parser coming along guilhermeblanco ?
- [13:16] <guilhermeblanco> I wrote more a few lines yesterday night... UPDATE and DELETE are already working
- [13:16] <guilhermeblanco> SELECT is complicated...
- [13:16] <airox> Will there be support for things like expressions ?
- [13:16] <guilhermeblanco> I'm working step by step to not miss anything
- [13:17] <airox> DATEADD and such ?
- [13:17] <guilhermeblanco> airox: yes
- [13:17] <airox> Nice.
- [13:17] <romanb> DATEADD? is that portable?
- [13:17] <guilhermeblanco> romanb: no... but DQL accepts functions from DBMS
- [13:18] <romanb> DQL will support as many portable expressions as possible
- [13:18] <romanb> guilhermeblanco: yes, but only with portability disabled
- [13:18] <guilhermeblanco> it just transports to the SQL, without taking care.
- [13:18] <romanb> then it accepts all of them
- [13:18] <guilhermeblanco> hmmmmmm dunno...
- [13:18] <romanb> ??
- [13:18] <guilhermeblanco> well... I think we can apply this:
- [13:18] <airox> Well adding something to a date could me made portable offcourse.
- [13:19] <guilhermeblanco> if function is in portability list, use it... otherwise, print it in sql just as it is
- [13:19] <romanb> DQL = fully portable. *by default* DQL must not allow any expressions it cant convert properly for all supported dbms
- [13:19] <guilhermeblanco> do not need to keep tracking portability on/off, and other stuff
- [13:19] <romanb> only if portability of expresions is disabled explicitly
- [13:19] <guilhermeblanco> hm
- [13:19] <romanb> then it should let them tthrough
- [13:20] <guilhermeblanco> ok
- [13:20] <guilhermeblanco> need to keep that in mind
- [13:20] <airox> No, write it down. ;)
- [13:21] <romanb> that will just be fantastic. currently you can disable expression portability but the (old) parser still cant handle lots of them properly and fails ... instead of letting them through
- [13:24] <airox> Would it be wise to schedule some times to brainstorm about testcases ?
- [13:24] <airox> For the DQL parser.
- [13:24] <guilhermeblanco> wait... romanb I don get them the final decision
- [13:24] <guilhermeblanco> airox: I try to write it down test cases when I finish the statement or I add something new
- [13:25] <guilhermeblanco> The last 2 days I added a lot of things, rewrote others...
- [13:25] <guilhermeblanco> I need to add a lot of test cases yet
- [13:25] <guilhermeblanco> for delete, mostly...
- [13:25] <romanb> guilhermeblanco: by default DQL = fully portable = error on any expressions it cant convert for all dbms. expression portability off => it lets them through
- [13:25] <guilhermeblanco> romanb: but what about the ones DQL can still handle?
- [13:26] <romanb> ??
- [13:26] <airox> guilhermeblanco: Yeah, but more testcases from a blackbox perspective, like adding correct states etc
- [13:26] <guilhermeblanco> for example... let's suppose we have DATEADD as not portable and MONTH as portable...
- [13:26] <guilhermeblanco> if we put portability = off
- [13:26] <guilhermeblanco> how would MONTH be handled?
- [13:27] <guilhermeblanco> by the DQL portability or simply output it to sql and let dbms decide
- [13:27] <guilhermeblanco> ?
- [13:27] <romanb> guilhermeblanco: MONTH would be handled the same as before
- [13:27] <guilhermeblanco> hm... just like as I thought
- [13:27] <guilhermeblanco> =)
- [13:28] <guilhermeblanco> we'll need later a list of portably functions
- [13:28] <guilhermeblanco> wow... that will be really cool to play with
- [13:28] <romanb> just look in the expression classes
- [13:29] <guilhermeblanco> romanb: sure
- [13:29] <guilhermeblanco> let me add this talk into pastebin and plce it in NewDqlApi
- [13:29] <romanb> guilhermeblanco: maybe you can use the existing expression classes in the parser to get the portable SQL for the portable expressions
- [13:29] <romanb> since the curren expression classes do exactly that
- [13:30] <guilhermeblanco> romanb: some of them will need to be rewrited (under SqlBuilder name)... but yes, that's the idea
- [13:30] <airox> guilhermeblanco: MONTH imho would be portable, but will be the same for a lot of dbms..
- [13:30] <romanb> yea
- [13:30] <guilhermeblanco> airox: I just gave the example...
- [13:30] <airox> guilhermeblanco: sorry, can't keep up with this :)
Posted by guilhermeblanco on Fri 11 Apr 17:33
report abuse | download | new post
Submit a correction or amendment below (click here to make a fresh posting)
After submitting an amendment, you'll be able to view the differences between the old and new posts easily.