Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Firebird prioritized over MySQL?Firebird prioritized over MySQL?
Previous
 
Next
New Post
3/31/2006 9:43 AM
 
Another thing to consider, is that it was only recently that MySQL added stored procedures -- and that, I am sure, was a big part of the decision on whether to develop a provider for it.  A truly flexible provider would be almost impossible without stored procedures.

Now, however, given the provider model that has been established, if MySQL support is that important, it is time for somone in the community to step forward to build the provider for it, just like we have seen with Firebird.
 
New Post
3/31/2006 11:48 AM
 

I am the Core liaison working with Sanjay on the Firebird provider. The reason that is a Core project is because it was started independently and the Core wanted to support it. The Core DOES want a MySQL provider and I have been tasked with helping bring that about.

I haven't "put the word out" yet because I was waiting for the Firebird provider to be finished because I was hoping we could borrow a bunch of code from it. You see the "big issue" with creating a provider is handling the membership provider. The current DotNetNuke membership provider is Microsoft's membership provider and it works with SQL server. Sanjay created code to make it work with Oracle and he is using the same code for the Firebird project.

Sanjay's code is the key that got the Firebird provider off the ground.

However, there are changes coming with DNN 4.1/3.1 to the membership provider. We are "un-coupling" DotNetNuke from the Microsoft membership provider and making a layer that sits above it that should make creating a alternate membership provider easier. That may mean that there wont be much code to borrow so we should just move ahead.

So my current plan is to wait for DNN 4.1/3.1 and then "put the word out" that we are looking to form a MySQL team.



Michael Washington
http://ADefWebserver.com
www.ADefHelpDesk.com
A Free Open Source DotNetNuke Help Desk Module
 
New Post
3/31/2006 12:19 PM
 
Actually, believe it or not, stored procedures are actually looked down upon in a lot of situations. Microsoft uses (and seems to recommend) them very heavily, but not everything that Microsoft says and does is necessarily the best practice. I'm used to working in enterprise environments that are built on flexibility, including portability between database systems, when appropriate. Because of this, proprietary code, such as stored procedures, is looked down upon and avoided where possible. I know there are benefits to them, but that has to be weighed against the deficits, such as this one. In some environments, it's just not an option. This typically means that there'll be more work to create providers for other databases - if SQL scripts were managed differently, this would be an easier migration.

On a side note, stored procedures aren't required for data providers, so this argument has absolutely no merit.

Let me say that I prefer to avoid stored procedures in most circumstances, but that comes from my experiences. I do know their benefits and think they should be applied smartly, as anything else goes. I'm neither for or against MySQL or Firebird (or SQL Server, for that matter).

Michael Flanakin | Microsoft Consulting Services
www.michaelflanakin.com
 
New Post
4/3/2006 10:10 AM
 
Stored procedures are NOT looked down upon in MOST situations. It isn't a MS issue, its a portability issue.

Being able to run an app on many different DB backends is easier to do, IMO, when DB access is abstracted away from the actual application code.

Being able to change DB access procedures without having to recompile and redistribute your application is a much better design than inline SQL.

Take DNN for example.

Having a provider based DB access model allows for what is happening in our community; for the community to write different providers for different DB backends when the need arises, without having to recompile or redistribute the application.
 
New Post
4/3/2006 1:57 PM
 

I have to agree with you there.  It's much easier to change the code in a handfull of sprocs than it is sorting through a bunch of source code looking for all the embedded SQL and recompiling the app.

I would much rather change 30 SPs than hunt for hours through code I may or may not have written looking for SQL that is most likely build dynamicly and hiding all over the place.

just my .02 


Paul Davis
 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Firebird prioritized over MySQL?Firebird prioritized over MySQL?


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out