Symphony.

We're in the process of building an extension for Discount codes and I'd like to know if there are any conventions to building the SQL retrieval of Section entries from the DB?

Is there docs on the best practice for this?

I'm also very interested in this. See my ramblings and questions here.

I'd like to know if there are any conventions to building the SQL retrieval of Section entries from the DB?

I guess using SymQL could be considered a best practice (example here), but I'm also struggling with this every time I have to get my hands dirty when customizing stuff, especially regarding security:

• Is Symphony's database class escaping queries internally (if not, why not)?
• Do we have to escape queries ourselves in extensions, datasources and events?
• How to secure queries correctly without being redundant?

Is there docs on the best practice for this?

Would be really helpful to have an article on database stuff for extension developers.

Btw. what's the difference between Tutorials and Articles on getsymphony.com. Just legacy?

There is of course the natural API for Symphony Objects, but SymQL was made to avoid using it.

• SymQL, as far as I remember, follows Symphony's standard of escaping all queries.
• If you're writing vanilla SQL, always escape your queries.
• Use sprintf to insert values into the query.

It would certainly be helpful to have an article, it is on the list, but as with all the docs, they stopped a while back. They are due to be rekindled this year for the new site.

I'm sure I remember a discussion about SymQL being a core extension, or even in the core, for devs to use to write queries, but then you (Jens) started talk about PDO etc, so I think the discussion expanded into creating an ActiveRecord approach to our database interactions. I know little of this as I kept out of that discussion though.

Personally? SymQL.

SymQL, as far as I remember, follows Symphony's standard of escaping all queries.

So I don't need to use sprintf because SymQL already uses it internally?

but then you (Jens) started talk about PDO etc

I know I know, but the result of the discussion has blown things totally out of proportion in my opinion, so I guess the quick and simple implementation I initially thought about (just swapping the old for a new database class which uses PDO) is no longer on the table. Sometimes I really hate open source... :/

I'm sure I remember a discussion about SymQL being a core extension, or even in the core, for devs to use to write queries

Would still be useful, even with a new database class.

Can of worms = open :) My work here is done :p

SymQl seems the right way to approach this and adding it to core would make sense for a lot of situations, but as we all know.. "Keep it lean, keep it mean" :)

I'm working on a Section retrieval of entries to export as different data types for download.. txt,csv,xls etc.. Yes I know importcsv is available, but I want to get to grips with the db without using others work in order to grasp more of what is possible.. #nutter