I am trying to make a pi base extension compatible with typo3 7.6.4. But I am unable to make the compatible version of the following code
$this->feUserObj = tslib_eidtools::initFeUser();
// Connect to database:
tslib_eidtools::connectDB();
It throws the error : Class tslib_eidtools not found. How can i convert the tslib_eidtools class, so that it gets compatible with typo3 7?
In Core File of TYPO3 7.6 LTS the database connection establishing code is located in core/Classes/Database/DatabaseConnection.php. You don't have to create the object of this class.
You could get the DB Object and Connection Parameters from the TYPO3 Globals Constant $GLOBALS['TYPO3_DB']. Refer Click Here
You could able to write the custom mysql queries using this global object.
Example :
$results = $GLOBALS['TYPO3_DB']->exec_SELECTgetRows (
$select_fields,
$from_table,
$where_clause,
$groupBy= '',
$orderBy= '',
$limit= '',
$uidIndexField= '' );
TYPO3 "database wrapper" class (new in 3.6.0) This class contains
abstraction functions for executing INSERT/UPDATE/DELETE/SELECT
queries ("Query execution"; These are REQUIRED for all future
connectivity to the database, thus ensuring DBAL compliance!)
functions for building SQL queries (INSERT/UPDATE/DELETE/SELECT)
("Query building"); These are transitional functions for building SQL
queries in a more automated way. Use these to build queries instead
of doing it manually in your code!
mysqli wrapper functions; These are transitional functions. By a
simple search/replace you should be able to substitute all mysql*()
calls with $GLOBALS['TYPO3_DB']->sql*() and your application
will work out of the box. YOU CANNOT (legally) use any mysqli
functions not found as wrapper functions in this class! See the
Project Coding Guidelines (doc_core_cgl) for more instructions
on best-practise
Also this connect() method you wont need to use in most of the cases from TYPO3 6.2
Related
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.
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.
I have one website that uses EF 4.4 (.NET 4.0 version of EF 5.0) that uses Code First against an existing database. I use the Devart oracle data provider which requires a workaround because of casing issues with the model type.
It makes the Devart provider recognize lowercase datatypes to interpret the schema. (Or something along those lines)
This works properly, until the control within this website, built on EF 4.1 Database First (Also against an existing database) tries to load. The Devart provider seems to be shared across the websites, and it results in errors about the provider not being able to recognize the datatypes (correctly) in all caps, because of the previous workaround to make it work in Code First.
Is there a workaround for this, or do I have to convert the Database First approach to Code First?
Edit: Here is the related workaround code. I seem to have lost the forum post I got it from. I believe it was on the Devart forums:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
config.Workarounds.ColumnTypeCasingConventionCompatibility = true;
... initialization code here ...
base.OnModelCreating(modelBuilder);
}
And the related error is this:
System.Data.MetadataException: Schema specified is not valid. Errors:
Model.ssdl(205,6) : error 0040: The Type CHAR is not qualified with a namespace or alias. Only primitive types can be used without qualification.
Model.ssdl(206,6) : error 0040: The Type VARCHAR2 is not qualified with a namespace or alias. Only primitive types can be used without qualification.
There are a bunch more, but they're all the same error with different lines and data types.
The Devart provider seems to be shared across the websites
After the ColumnTypeCasingConventionCompatibility option is set, it determines the behaviour of the current application domain (web site). The process (web server) may run several application domains with different values of ColumnTypeCasingConventionCompatibility.
The value of ColumnTypeCasingConventionCompatibility for the particular application domain depends on the Fluent Mapping property of the DbContext template used for the model in web site. Fluent Mapping=true must be used with ColumnTypeCasingConventionCompatibility=true, and vice versa: Fluent Mapping=false must be used with ColumnTypeCasingConventionCompatibility=false.
You can set ColumnTypeCasingConventionCompatibility for a web site in the following alternative ways:
a) in your code before the first usage of the context (e.g., in a static constructor of the context or in the Main method of your program, etc)
b) in *.config. For example:
<configuration>
<configSections>
<section name="Devart.Data.Oracle.Entity"
type="Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfigurationSection,
Devart.Data.Oracle.Entity, Version=7.5.179.0, Culture=neutral,
PublicKeyToken=09af7300eec23701" />
</configSections>
<Devart.Data.Oracle.Entity xmlns="http://devart.com/schemas/Devart.Data.Oracle.Entity/1.0">
<CodeFirstOptions ColumnTypeCasingConventionCompatibility="true"/>
</Devart.Data.Oracle.Entity>
</configuration>
I've got a store procedure call returning a recordset whith field unknown in advance. For some interop reason I need to make it working on 3.5, so I don't have any dynamic support.
Is there some built-in solution in dapper? I did not find any by myself.
If there is no such a solution, does it make sense ( and does it work ) to create on the fly a type exposing the property I would fetch ?
EDIT
I managed to add a completely external solution ( without tweaking the original codebase ) by creating a dynamic object in c# 3.0.
Here is the extension dapper code
and here the factory for the dynamic object.
Well, actually the dynamic support in dapper is implemented via ExpandoObject, which is basically just a dictionary. It would be pretty simple to tweak the existing code to return IDictionary<string,object> instead of dynamic in the case of 3.5
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.