Re: Possible MySQL Bug

[Nala Ginrut]

Hi Jaft!
Thanks for the work!

First, I don't think FPRM can cover every syntax of all supported
DB. Please treat FPRM as ORM, the difference is that we do it in
more functional way. So it's still a RM (relational mapping), and
there's the limitation of the RM.

Artanis provides 3 ways combination to try to solve part of the issues of
ORM, so we don't have to do everything in FPRM.
For now, we can just add the simplest syntax of deletion to FPRM
(distinct the syntax of each DB). If folks need more, we can try to add
some. But please remember that we will have SQL-mapping for the most
complex cases. SQL-mapping is a SQL string template to interact with
Scheme context easily, so that folks may write very complex SQL code
directly, which can be well managed by Artanis, and you may interact
with it conveniently.

After all, SQL itself is the best way to interact with DB profoundly.

However, I don't have time to polish SQL-mapping at the moment. For most
users, I don't think the requirements are complex enough to use
SQL-mapping.

So the point here is that we don't have to make it too complex in FPRM,
just try the simplest way first.


Best regards.

Jaft writes:
>  I didn't have much time to work on the PR this weekend, sadly, but I think I 
> found three sites that lay out the possible commands for each one: 
> https://www.postgresql.org/docs/10/sql-delete.html, 
> https://dev.mysql.com/doc/refman/8.0/en/delete.html, and 
> https://sqlite.org/lang_delete.html.
> So the required elements for all three are the same (DELETE FROM <table>) 
> while all three accept a WHERE statement.
> All the differences seem to be in the optional keywords; so, if only 
> implementing the required elements and adding another branch like 
> ((row-delete) (apply row-delete tname args)) to the function gen-sql, 
> row-delete could just be written as
>
> (define (row-delete tname t)  (->sql delete from table tname t))
>
> But, to account for the optional keywords, t would need to be parsed since 
> some of the keywords belong before the DELETE keyword while some go after the 
> DELETE but before the FROM.
> I mostly bring it up since there really aren't any examples I see to base it 
> off of (I don't think); all the other ones seem to have pretty precise number 
> of arguments they expect. I guess we could have row-delete take an args list 
> for the last parameter and it could get parsed for particular keywords.
> But I guess I just wanted to check how you'd prefer to handle that or how 
> much of the optional elements of each command you wanted to be implemented, 
> since I wasn't sure.
> Jonathan    On Thursday, October 29, 2020, 1:55:32 AM CDT, Nala Ginrut 
> <mulei@gnu.org> wrote:
>
>
> Jaft writes:
>
>>  Nala writes:
>>> I think what you're looking for is make-table-modifier, however, the> 
>>> delete operation is missing somehow, I may forgot to add it.
>> Oh, cool; adding to an already existing make-table- function makes this a 
>> lot easier.
>>> The modifications in mysql/postgresql/sqlite3 are different, so we have> to 
>>> take care of them.
>> They are? Granted, I haven't done a lot of extensive SQL but I thought they 
>> all followed the basic
>>
>> DELETE FROM <table_name>WHERE      <condition>;
>
> I haven't checked the differences, but you may see what I've done for
> other operation like alter/drop...etc. Usually, there's slightly
> difference in SQL syntax. Although you may only focus on MySQL/MariaDB
> for this PR, you may want to have a look around others.
>
>>> The FPRM is still experimental and not well tested yet, but I encourage> 
>>> you to report any exceptions.
>> Funnily enough, – not directly in the fprm.scm file but used by it – I 
>> noticed in ssql.scm that both the last option for both sql-update and 
>> sql-delete call ->where with the WHERE portions being run through sql-where 
>> before being sent to ->where (lines 173 and 186).
>> But ->where uses sql-where in both possible cases so you end up basically 
>> sending a string to sql-where in ->where. I think line 173 is supposed to be
>>
>> (->where end (sql-update table set pairs) rest ...)
>>
>> and line 186
>>
>> (->where end (sql-delete from table) rest ...)
>>
>> If I'm correct, would you want me to create a PR to correct those? Or just 
>> roll those fixes into the PR for deleting rows in FPRM?
>
> I think you're right!
> It's a bug, and I think you can create a PR for it.
> I'm looking forward to our new contributor. ;-)
>
>> Finally, should I fork from master and make the PR to there or use another 
>> branch? My assumption is master but just thought I should double check.
>
> For this thread, I think there should be 2 independent PR.
> And yes you can fork master branch.
> For now, it's OK to use fork. If we have more contributors, I'd like to
> use branch-based PR. Anyway, let's focus on fork-based PR right now.
>
> Best regards.


--
GNU Powered it
GPL Protected it
GOD Blessed it
HFG - NalaGinrut
Fingerprint F53B 4C56 95B5 E4D5 6093 4324 8469 6772 846A 0058

signature.asc
Description: PGP signature