Calling a stored procedure in Postgresql through F# and Npgsql - postgresql

I am trying to call a stored procedure in postgresql from F# using the Npgsql type provider.
Currently, I am connected to the database as follows:
open System
open System.Data
open System.Data.Entity
open System.Data.Linq
open Microsoft.FSharp.Data.TypeProviders
open Microsoft.FSharp.Linq
open Npgsql
open NpgsqlTypes
type internal dbSchema = SqlEntityConnection<ConnectionString="**my connection string**", Provider="Npgsql">
let internal db = dbSchema.GetDataContext()
However, I only see the tables on the db type, not any of the stored procedures. Is there a way to use the stored procedures in a statically typed manner through the type provider, instead of just calling the raw query string?

I know this question was asked along time ago, but I thought I would add a reference to the SqlProvider. This has recently had support for PostgreSQL added to it and it includes support for SPROCS.
[<Literal>]
let connStr = "User ID=postgres;Password=password;Host=POSTGRESQL;Port=9090;Database=hr;"
[<Literal>]
let resolutionFolder = #"D:\Downloads\Npgsql-2.1.3-net40\"
type HR = SqlDataProvider<ConnectionString=connStr,DatabaseVendor=Common.DatabaseProviderTypes.POSTGRESQL, ResolutionPath = resolutionFolder>
let ctx = HR.GetDataContext()
ctx.Procedures.ADD_JOB_HISTORY(100, DateTime(1993, 1, 13), DateTime(1998, 7, 24), "IT_PROG", 60)
//Support for sprocs that return ref cursors
let employees =
[
for e in ctx.Functions.GET_EMPLOYEES().ReturnValue do
yield e
]
Where the resolution folder points to the location of the NPGSQL .NET assemblies.

From the look at you are seeing, it looks like this is not supported somewhere between npgsql, f#, and npgsqltypes. The chance of you getting a good answer here is very low because it would require someone with a strong understanding of this language, the architecture of it, and where exactly each piece of the puzzle relies. It might also require debugging to see what is going wrong.
The previous suggestions were:
Since PostgreSQL doesn't really have stored procedures per se, F# might not recognize them, and
npgsqltypes might be missing some important aspects on the mapping.
I would expect that npgsql would not be where I would start looking at this because, in theory, the type provider should be able to do the lookups itself.
So I would recommend getting on relevant email lists and asking about this assuming it to be a problem with your type provider. Anyone who knows enough to troubleshoot will probably be on those email lists.

Related

How create a persistentStore to MySQL with Aqueduct?

I'm trying to create a context with dataModel and persistentStore... Follow the code below working with PostgreSQL:
#override
Future prepare() async {
logger.onRecord.listen((rec) => print("$rec ${rec.error ?? ""} ${rec.stackTrace ?? ""}"));
final dataModel = ManagedDataModel.fromCurrentMirrorSystem();
final persistentStore = PostgreSQLPersistentStore.fromConnectionInfo(
"heroes_user", "password", "localhost", 5432, "heroes");
context = ManagedContext(dataModel, persistentStore);
}
I want use MySQL instead PostgreSQL, I dont find any tutorial using it.
Here is the general procedure using another type of database:
Find a MySQL Dart package. (maybe this one)
Create a class that extends Aqueduct's PersistentStore.
Implement the abstract methods for MySQL. (For reference, see how PostgreSQLPersistentStore does it in PostgreSQL.)
If you are using authentication, do the same for AuthServerDelegate. (For reference, see how ManagedAuthDelegate does it in PostgreSQL.)
Create lots of tests to check your work.
My recommendation:
Use the default PostgreSQL implementation. It will take a lot less time to learn than it will to implement everything on your own for MySQL. The default implementation is probably also better tested. With the ORM, you don't even use much raw PostgreSQL code anyway, which itself isn't significantly different than raw MySQL code.
You could also check out the Angel server, which seems to be more modular than Aqueduct, but you are still going to have to implement your own MySQL service. See this.
Do as much development as you can without choosing a framework or database. As a principle of clean architecture, these are details. If possible, abstract them away. See Clean architecture for the rest of us.

NsPerstentContainer name in Appdelegate conventions in Core Data setup

I'm programming my fist SwiftApp got stuck setting up Core data. Since I'm integrating it into existing code I can't have Xcode set it up on Prohect init anymore. Furthermore I als want to understand what the lines of code actually do. Since all Core libraries are secret I am stuck with Apple's Docs which are not very clear on the matter.
Pfew... with that out of the way here is the question; What is the significance of the name passed to...
let container = NSPersistentContainer(name: "Core_Data")
...in the App Delegate file. I had set it up before but during compilation Xcode complained that it could not find the specified Name's module. Changing it to my project's name, the core data file I had created or the name of the Database passed to the menu when adding a Core Data file did not seem to help at all. Searching the web and a few tutorials people just fly over it and it is still very much unclear to me.
Any help would be much appreciated!
The string passed there is used for two things. If you were to pass the string Foo, Core Data would attempt:
To find the data model by looking for Foo.xcdatamodel or Foo.xcdatamodeld.
To find (or create) the persistent store, using the name Foo.sqlite.
Even an incorrect string value (i.e. one that doesn't match the name of your data model) should not cause a compilation error. It might cause an error at run time if iOS can't find the named data model.

UniData List all avaiable subroutines / All parameters

I am trying to wrap some UniData Subroutines to SOAP Web Service. I'm planning to use C# and UODOTNET library (IBM U2 Data Management Interface for .NET). Also I'm looking to create an engine to read all the available Subroutines from data server and also reads all the required parameters and dynamically generate required codes for Web Service.
My code would be something like this:
var session = UniObjects.OpenSession(
"192.168.0.1",
"user",
"password",
"account"
);
var cmd = session.CreateUniCommand();
cmd.Command = "LIST SUBURB.INDEX"; // ?????
cmd.Execute();
var res = cmd.Response;
Question 1: Is there any command that I can use to retrieve the list of all available subroutines?
Question 2: Is there any command that I can use to retrieve list of all parameters for specific subroutine?
Cheers
The short answer is no.
The longer answer is yes, but with a lot of work.
Since you are asking this question, I'm going to assume you are missing a lot of generally knowledge about the platform. Hence to be able to do this you'll need to:
Learn about how VOC works, specifically how executable code can be catalogued here.
Learn about the CATALOG and how cataloguing programs globally, locally and direct differ.
Understand how your system in particular is designed. Some places have everything directly catalogued in the VOC, others are a mix. If the former, it'll be easier for your question.
Once you understand the above, you'll know how to get a list of all executable programs from VOC, local catalog and global catalog. For example, a simplified example for the VOC is the UniQuery command LIST VOC WITH F1="C".
The hard part is getting the parameter list, of which there isn't any system command. To do this you have 2 options.
Reverse engineer the byte code of every subroutine and tease out the number of parameters
If you have access to the related source code, parse it to generate the list.
Just wanted to add a comment on this one, in UniData there is a MAKE.MAP.FILE command that will identify Programs and Subroutines ( and the number of parameters) which puts the information in the '_MAP_' file. This does not tell you what the parameters are used for, but it helps.

Entity Framework Context Not Acting As I Expected

I am seeing something in Entity Framework that has me thinking that I either completely misunderstand how the database context works, or EF is actually broken (and I know that most likely means I just don't get it).
Consider the following scenario:
In the database I have a bunch of Student Attendance records, and they all have a code marked as P for present.
Then we have something akin to the following:
public void SetAttendance(int dayId,int attendanceId, int attendanceId, String mark)
{
updateAttendance = new StudentAttendance()
{
Code=String.Empty,
AttendanceId=attendanceId,
DayId = dayId
};
context.Attach(updateAttendance);
//I don't save changes yet because I now need to do some logic
var markedAttendanceCount = context.StudentAttendance.Where(att=> !String.IsNullOrEmpty(att.Code) && att.DayId == dayId).Count();
var allAttendanceCount = context.StudentAttendance.Where(att=> att.DayId == dayId).Count();
var updateDay = new ClassDay()
{
DayId = dayId,
AllMarked = markedAttendanceCount = allAttendanceCount
};
context.Attach(updateDay);
context.SaveChanges();
}
I would expect that if I were to call that SetAttendance method as follows:
myworker.SetAttendance(10,20,String.Empty);
That it should properly recognize that the attendance for the day is not fully marked. What I am instead seeing is that my look int query against context.StudentAttendance is asking the database. As such, my detection of the day's status change is always one behind.
I thought that the context was basically supposed to be smart enough to let you write something like this. In essence, I had always had the impression that the db context lets you essentially work with a serializable transaction kind of behavior. As you make changes to the data through your context, those changes will reflect in queries against the context. Am I missing something?
EF doesn't work that way, no. For performance reasons basically.
However, context.StudentAttendance.Local exposes a set containing the added entities. It also contains any entity previously loaded by the context in a query. If you like you can load the whole DbSet into memory as described here: https://msdn.microsoft.com/en-au/data/jj592872.aspx however this is not advisable for large datasets.
Also, you should be using context.Add() rather than context.Attach(). The latter is for entities which already exist in the database.
It's true that you don't fully understand how EF works, but I think EF is to blame for that. You're asking a very good and valid question.
NHibernate, as opposed to EF, has this AutoFlush feature. This means that "at any moment" it may commit changes to the database in order to keep local changes and database content in sync without the developer's intervention. In your case, it would have saved the new StudentAttendance before querying existing ones from the database. So if the new one matched the predicate (DayId == dayId) it would have contributed to allAttendanceCount. This feature, when understood well, allows for a very intuitive way of dealing with data, exactly the way you expected EF to behave.
The truth is, however, that AutoFlush has always eluded developers, so they often just disabled it. As a developer you want to have full control, you don't want to depend on some smart feature that seems to have a life of its own. (Even though the reality is that you probably just didn't take the time to fully get it).
I can imagine that for this reason, the EF team decided not to implement such a feature.
So what to do in your case? Not easy. When after adding the new StudentAttendance you'd do...
context.StudentAttendance.Load();
(assuming that you have a DbContext, though your "context.Attach" doesn't seem to be in line that).
And then...
var allAttendanceCount = context.StudentAttendance
.Local // <= Local! Includes the new item
.Where(att=> att.DayId == dayId)
.Count();
...you'd have the desired result. But of course, loading all StudentAttendance records locally is a tremendous overkill.
One simple alternative is to to the count as you do now and add 1 to it.
Another alternative is to mimic autoflush, sort of, and save the new StudentAttendance before doing the count. But then you'd have to wrap everything in a TransactionScope. One advantage is that you'd have the very latest value of allAttendanceCount.

Is newest version of MS Enterprise Library compatible with older versions like 3.1

This current project I've been assigned uses the Version 3.1 levels of:
Microsoft.Practices.EnterpriseLibrary.Common;
Microsoft.Practices.EnterpriseLibrary.Data;
As I try to get to know more about the capabilities of the Ent Lib, I am running into lots of articles and doc about various versions (3.1, 4.0, and 5.0 I think).
In general do the newer versions work with application code written for an earlier release of the Ent Lib? I haven't surveyed all of the source code in this app I've inherited but I think only the "basics" of the Data Access Application Block are being used. Here is a typical piece of code:
public override List<Erx.Action> GetAll(bool bIsActive)
{
Database db = null;
DbCommand cmd = null;
List<Erx.Action> lst = null;
IDataReader iRdr = null;
try
{
db = DatabaseFactory.CreateDatabase();
cmd = db.GetStoredProcCommand("Mst_GetAllCorrectiveAction");
db.AddInParameter(cmd, "#CorrectiveActionID", DbType.Int32, -1);
db.AddInParameter(cmd, "#IsActive", DbType.Boolean, bIsActive);
iRdr = db.ExecuteReader(cmd);
lst = new List<Erx.Action>();
while (iRdr.Read())
{
Action objAction = new Action();
objAction.CorrectiveAction = iRdr["CorrectiveAction"].ToString();
objAction.CorrectiveActionID = int.Parse(iRdr["CorrectiveActionID"].ToString());
objAction.IsActive = (bool)iRdr["IsActive"];
lst.Add(objAction);
}
}
catch (Exception ex)
{
throw ex;
}
finally
{
db = null;
iRdr.Close();
if (cmd != null)
{
cmd.Dispose(); cmd = null;
}
}
return lst;
}
Frankly, this does not seem to offer much beyond regular ADO.Net but maybe the newer versions make things simpler (I've heard some very good stuff about Unity).
I just installed Ent Lib 4.1 and dug closely into the doc and found this in the "Introduction to the Data Access Application Block":
Changed Features, Version 3.1 and Later
In general, applications built using earlier releases of the Data Access Application Block will function with this release without the need for any code changes. It may be necessary to update the references to refer to the new assemblies and to update the configuration files to reference the correct version of the assemblies. However, some changes were made to the Data Access Application Block in version 3.1 (May 2007), which may affect applications written for earlier versions if you upgrade to the current version of Enterprise Library. The following sections describe these changes.
The .NET Framework 2.0 TransactionScope Class
To take advantage of the .NET Framework 2.0 TransactionScope class, there have been changes to some of the Database class methods in version of Enterprise Library from version 3.1 onwards. These methods, such as ExecuteNonQuery, have been modified to recognize when a TransactionScope instance is active by replacing the GetConnection method with the GetOpenConnection method. If you have written a class that inherits from the Database class, you will need to rewrite your code to take these changes into account. If you continue to use the GetConnection method, you will receive a compiler warning. In addition, if your application uses the ExecuteXmlReader method, you may need to rewrite your code to test to see whether a TransactionScope instance is active before closing a connection.
For more information, see Using the TransactionScope Class. For an example of how to use the ExecuteXMLReader method, see Retrieving Multiple Rows As XML.
strong text
SQL Server Compact Edition
Enterprise Library 3.1 – May 2007 and later supports SQL Server Compact Edition (CE). SQL Server CE provides the essential features of a relational database and is intended for desktop and mobile applications that need a local data store but do not require the full functionality of SQL Server. For more information, see the section "Using SQL Server CE" in Creating a Database Object.
I am still trying to get a sense of how truly useful this DAAB is. It seems like a tremendous amount of reading of doc is required to end up writing just a little less code than otherwise required with ADO.NET un-aided by the DAAB. I guess if one wanted to provide for an easier switch to say, Oracle [from MS SQL Server), this is a useful way to configure things.
If you have unit tests,port to new and run and see,if you have Resharper it can analyse your solution in VStudio and point out the errors.It will take you time.