nhibernate / nhibernate.spatial Goto Github PK

MySQL57SpatialDialect needs a separate test project, as the changes are not reconcilable with the old MySQL tests.

Hello

Would you upgrade the project and add also a new version for the SQL Server 2012 dialect?

Hi,

we found an issue that currently blocks us very hard. We want to activate nhibernates OptimisticLock feature.

        this.OptimisticLock.Dirty();
        this.Version(x => x.ModificationTime).Column("MT").Generated.Always();

but I we changed an entity with a geotype it generates sql like

declare @p3 sys.geography
set @p3=convert(sys.geography,0xE61000000114159DAF9215EC4A40F19888688E4725400297DD170AEC4A405BA7C51B92472540)
declare @p5 sys.geography
set @p5=convert(sys.geography,0xE6100000011469248B700CEC4A405BA745E98F4725400297DD170AEC4A405BA7C51B92472540)
exec sp_executesql N'SELECT * FROM LineObjects WHERE ID = @p1 AND PointCloud = @p2',N'@p0 [geography],@p1 int,@p2 [geography]',@p0=@p3,@p1=1822,@p2=@p5

which is followed by that error:
Invalid operator for data type. Operator equals equal to, type equals geometry
you must use the geography equals function: https://msdn.microsoft.com/en-us/library/bb933809.aspx (STEquals) then it works...

This issue was raised 6 years ago and still seems to be unresolved: http://stackoverflow.com/questions/2427548/criteria-spatialrestrictions-iswithindistance-nhibernate-spatial

One possible solution is given in the link above.

Currently one of the tests (OrderByDistanceHql) enters an infinite loop because the test project is set up to use PostGis20Dialect without overriding the property GeometryType in the projection fixture. A separate test project is needed for this dialect to overcome this problem.

Hello

Would you consider create a nuget package for the library with the required references?

Thanks

It may be possible to continue @FObermaier's work on the Spatialite dialect as mentioned by @peetw in #5. What needs to be done is to fork the Spatialite dialect and bring it up to speed with upstream, and then submit a pull request in a separate branch which @peetw can fork and improve further.

It appears as if it was originally created for use with the third-party MsSqlSpatial extension for MS SQL 2005 databases. The first MS SQL server version to officially support spatial data was 2008.

I think it might be time to deprecate and remove it?

Hi

I have the following code:

            IPolygon boundingBox = Geometry.DefaultFactory.CreatePolygon(Geometry.DefaultFactory
                                                                      .CreateLinearRing(new[]
                                                                   {
                                                                       new Coordinate(-101.20332217930151, 23.904319047265624), 
                                                                       new Coordinate(-99.3891350206985, -99.3891350206985),
                                                                       new Coordinate(-99.3891350206985, 27.373252152734374), 
                                                                       new Coordinate(-101.20332217930151, 27.373252152734374),
                                                                       new Coordinate(-101.20332217930151, 23.904319047265624)
                                                                   }), null);

var result2 = session.QueryOver().WhereSpatialRestrictionOn(p => p.Location).Intersects(boundingBox).List();

and throws the following exception ExceptionObject = {"Must declare the scalar variable "@p0"."}

the last part of the generated query is "WHERE this_.Location.STIntersects(@p0) = 1".

I hope that you help me with my issue.

Antonio Ramos

Hi pp,

I have some problems with the linq queries and the spatial datatypes. I want to make a search for all points in a certain distance. Here is a example:

this.pointObjectRepository.GetAllEntities().FirstOrDefault(x => x.Location.Distance(geoPoint1.Location) < 10);

pointObjectRepository is my repository and GetAllEntities is a session.Query() from nhibernate. geoPoint1 is from type NetTopologySuite.Geometries.Point. If I run it, I've got a NotSupportedException with 'Double Distance(GeoAPI.Geometries.IGeometry)'. It comes from

System.NotSupportedException: Double Distance(GeoAPI.Geometries.IGeometry)
bei NHibernate.Linq.Visitors.HqlGeneratorExpressionTreeVisitor.VisitMethodCallExpression(MethodCallExpression expression)
bei NHibernate.Linq.Visitors.HqlGeneratorExpressionTreeVisitor.VisitExpression(Expression expression)
bei NHibernate.Linq.Visitors.HqlGeneratorExpressionTreeVisitor.VisitBinaryExpression(BinaryExpression expression)
bei NHibernate.Linq.Visitors.HqlGeneratorExpressionTreeVisitor.VisitExpression(Expression expression)
bei NHibernate.Linq.Visitors.HqlGeneratorExpressionTreeVisitor.Visit(Expression expression, VisitorParameters parameters)
bei NHibernate.Linq.Visitors.QueryModelVisitor.VisitWhereClause(WhereClause whereClause, QueryModel queryModel, Int32 index)
bei Remotion.Linq.Clauses.WhereClause.Accept(IQueryModelVisitor visitor, QueryModel queryModel, Int32 index)
bei Remotion.Linq.QueryModelVisitorBase.VisitBodyClauses(ObservableCollection1 bodyClauses, QueryModel queryModel) bei Remotion.Linq.QueryModelVisitorBase.VisitQueryModel(QueryModel queryModel) bei NHibernate.Linq.Visitors.QueryModelVisitor.Visit() bei NHibernate.Linq.Visitors.QueryModelVisitor.GenerateHqlQuery(QueryModel queryModel, VisitorParameters parameters, Boolean root) bei NHibernate.Linq.NhLinqExpression.Translate(ISessionFactoryImplementor sessionFactory) bei NHibernate.Hql.Ast.ANTLR.ASTQueryTranslatorFactory.CreateQueryTranslators(String queryIdentifier, IQueryExpression queryExpression, String collectionRole, Boolean shallow, IDictionary2 filters, ISessionFactoryImplementor factory)
bei NHibernate.Engine.Query.HQLExpressionQueryPlan.CreateTranslators(String expressionStr, IQueryExpression queryExpression, String collectionRole, Boolean shallow, IDictionary2 enabledFilters, ISessionFactoryImplementor factory) bei NHibernate.Engine.Query.HQLExpressionQueryPlan..ctor(String expressionStr, IQueryExpression queryExpression, String collectionRole, Boolean shallow, IDictionary2 enabledFilters, ISessionFactoryImplementor factory)
bei NHibernate.Engine.Query.HQLExpressionQueryPlan..ctor(String expressionStr, IQueryExpression queryExpression, Boolean shallow, IDictionary2 enabledFilters, ISessionFactoryImplementor factory) bei NHibernate.Engine.Query.QueryPlanCache.GetHQLQueryPlan(IQueryExpression queryExpression, Boolean shallow, IDictionary2 enabledFilters)
bei NHibernate.Impl.AbstractSessionImpl.GetHQLQueryPlan(IQueryExpression queryExpression, Boolean shallow)
bei NHibernate.Impl.AbstractSessionImpl.CreateQuery(IQueryExpression queryExpression)
bei NHibernate.Linq.DefaultQueryProvider.PrepareQuery(Expression expression, IQuery& query, NhLinqExpression& nhQuery)
bei NHibernate.Linq.DefaultQueryProvider.Execute(Expression expression)
bei NHibernate.Linq.DefaultQueryProvider.Execute[TResult](Expression expression)
bei System.Linq.Queryable.FirstOrDefault[TSource](IQueryable1 source, Expression1 predicate)

the method object that is passed to if (!_functionRegistry.TryGetGenerator(method, out generator)) has a Fullname of 'NetTopologySuite.Geometries.Geometry.Distance(GeoAPI.Geometries.IGeometry)' but the registered method for distance has a litte bit other type: 'GeoAPI.Geometries.IGeometry.Distance(GeoAPI.Geometries.IGeometry)'

so the if-statement returns false and it crashed. How Can I Fix it?

The strange thing is:

var geoPoint1 = this.pointObjectRepository.FindByPrimaryKey(1);
var geoPoint2 = this.pointObjectRepository.FindByPrimaryKey(2);
Debug.WriteLine(geoPoint1.Location.Distance(geoPoint2.Location));

that works

Just to bring in the context from the emails

Stephen Bohlen

One suggestion re: the .MsSql2008 package...when you get to the pt where the package goes GA (e.g., "non-pre") I wonder whether it might be a good idea to add to the descr. of that package that the 2008 package supports SQL Server's Spatial extensions up through SQL Server 2012 (?). I'm thinking that a consumer of that package would otherwise have no way of knowing that it supported other that SQL Server 2008 (short of perhaps reading release notes which usually aren't visible until after the package is installed).

Right now, the description of all three packages is identical:

NHibernate.Spatial is a library of spatial extensions for NHibernate, and allows you to connect NHibernate to a spatially enabled database and manipulate geometries in HQL or in .NET code using NetTopologySuite, providing you with a fully integrated GIS programming experience.

If you add to the description something along the lines of ....

This package supports versions to .

...it might help make things clearer.

Now that I think about it, I guess a related question that comes to mind is this: how would a consumer of these packages for MySQL or PostGIS know what version(s) of those DBs are supported either? Should there be an e.g., .MySql5 suffix considered for the MySql package?

Once you set a package name in NuGet, that's an irreversible decision (at least in re: users updating to the newer packages via NuGet tooling), so we should probably make sure we're using a naming convention that makes coherent sense across packages before these are released for GA. Since few users (in my experience) do much reading about a package beyond inspecting its name in the NuGet dialog, the name is the first, best opportunity to 'advertise' the package's intent to consumers.

What are other's thoughts on this --?

Surya Pratap

Yes,
we did think of pushing SqlServer2012 as a separate package.

but that is just talk right now.

I am not sure what will be good, a per-vendor-per-version packages for the db's or just a per-vendor package

The first option puts in a lot of dependencies as soon as the vendors release new versions, later a lot of code migration will need to be done if we start depreciating older packages. But this will allow the user to upgrade selectively. One of the reasons for thinking of Sql2008 and Sql2012 is that the spatial dll's for the drivers have changed between versions. I am not sure about the case for other databases.

The second option will force users to upgrade db specific dll even if they are still using an older db version (which might not be as bad as it sounds) but it will allow deployment with fewer dependent dll's and easier maintenance.

All suggestions are welcome, contributors even more so ;)

Andreas Ravnestad

Hi!

I have thought some more about adding support for SQL Server 2012. I think one of the most important missing feature is the spatial aggregates which became available in 2012. These are:

• CollectionAggregate
• ConvexHullAggregate
• EnvelopeAggregate
• UnionAggregate

These are available for both Geometry and Geography.

In ISpatialDialect.cs the following method interface is defined: SqlString GetSpatialAggregateString(object geometry, SpatialAggregate aggregate);

Currently this method throws a “NotImplementedException” in the MsSql2008 dialect.

I am thinking that a good start may be to create a new MsSql2012SpatialDialect which subclasses the MsSql2008SpatialDialect and overrides this method and returns the proper aggregate string.

I am not sure whether this should be done in a new project or if the MsSql2008 module should be renamed and support multiple dialects. What do you think?

Currently there is a defunct test project for the Oracle dialect. This needs to be fixed and rigged on the build server.

        var factory = new GeometryFactory(new PrecisionModel(), 4326);
        var lineString = factory.CreateLineString(new[] { new Coordinate(10.663205085222556, 53.839650630871837), new Coordinate(10.663298874642745, 53.839602599750108) });
        Debug.WriteLine(lineString.Length); 

        var p1 = factory.CreatePoint(new Coordinate(10.663205085222556, 53.839650630871837));
        var p2 = factory.CreatePoint(new Coordinate(10.663298874642745, 53.839602599750108));
        Debug.WriteLine(p1.Distance(p2));

both return 0,000105372880733037 but it should 8,16680415531018

Using NHibernate.Spatial.MsSql v4.0.4.4001 with MsSql2008GeographyDialect.

Schema export broke with:
NHibernate.HibernateException : Incorrect syntax near 'MyOtherwiseOkTable'
at NHibernate.Tool.hbm2ddl.SchemaExport.Execute

Examining the ddl output, I notice that directly after creating the view
[some_schema].[NHSP_GEOGRAPHY_COLUMNS]
(with dot separator), the script attempts to
ALTER [some_schema][MyOtherwiseOkTable] DROP COLUMN [Geometry]
(without dot separator).

Adding a dot between schema and table name and re-running that db command, it runs fine.

It looks like in MsSql2008FunctionRegistration.GetSpatialCreateString the line
string quotedSchema = !string.IsNullOrEmpty(schema) ? adaptor.QuoteForSchemaName(schema) : string.Empty;
should instead be
string quotedSchema = adaptor.QuoteSchema(schema);
used elsewhere in that class, which does the null/empty check and otherwise appends StringHelper.Dot.

Not sure whether MsSql2008FunctionRegistration is the exact class for setting "NOT NULL" constraints for geometry/geography-type columns on MS-SQL-Server, however, somewhere in the processing chain, this information is lost.

This looks like another case of dialect breakage. MySQL versions prior to 5.7 returned geometry strings in a special manner handled by the class MySQLGeometryStringType. The fix is simply to change line 119 and 121 from:

    119: RegisterSpatialFunction("AsText", MySQLGeometryStringType.Instance);
    121: RegisterSpatialFunction("GeometryType", MySQLGeometryStringType.Instance);

to:

    119: RegisterSpatialFunction("AsText", NHibernateUtil.String);
    121: RegisterSpatialFunction("GeometryType", NHibernateUtil.String);

However, this brings about the need to subclass the MySQL dialect to preserve backwards compatibility. My suggestion is to name this subclass MySQL57SpatialDialect.

The reference to Microsoft.SqlServer.Types has proven to be quite annoying due to the manner in which it installs binaries and source code which is completely redundant in projects where deployment of these binaries are handled manually (which is a much better practice). This dependency should be removed from the NuGet package unless there are very good reasons to keep it.

So I just spent two days trying to Nhibernate.Spatial to run under a .net standard 2.0 app. There were several issues but the primary one has to do with the serialization of sql geometry/geography types. It just doesn't work because some of the underlying serializers aren't in the .net standard 2.0 version of System.Data. Nothing I did was able to get them to reliably load the full-framework version of system.data.

If I can work out a way to reliably read and write sql server geo-types without the dependence on the Microsoft.SqlServer.Types library would that be an acceptable solution?

Is there any reason why this property still returns false? Currently this means that FluentNHibernate's automapping maps Id columns using integer and a single "hibernate_sequence", rather than mapping them as serial with individual sequences for each table...

I'm not sure I understand the xmldoc comments and the TODO item seems to suggest it should have been changed back to returning true. I've certainly had success (mappings and schema generation all run fine) using the following derived class:

public class PostGisModDialect : PostGisDialect
{
    public override bool SupportsIdentityColumns
    {
        get { return true; }
    }
}

if I have a mapping code like

mapper.Class<GisPoint>(map => map.Property(col => col.Geom, prp => prp.Type<NHibernate.Spatial.Type.MsSql2008GeometryType>()));

and the model like

public class GisPoint
    {
                public virtual Guid Id {get; set;}

                public virtual double X { get; set; }

        public virtual double Y { get; set; }

        public virtual int SRID { get; set; }

        public virtual IGeometry Geom { get; set; }
     }

the database schema automatically generated takes GisPoint.Geom to be a small int.

this is caused if you set configuration like so

var configuration = new Configuration();
                configuration.DataBaseIntegration(c =>
                {
                    c.Dialect<MsSql2012Dialect>();
                    c.ConnectionString = connectionString;
                    c.KeywordsAutoImport = Hbm2DDLKeyWords.AutoQuote;
                    c.SchemaAction = SchemaAutoAction.Update;
                });

When i do NHibernate.Spatial.Metadata.Metadata.AddMapping( cfg, NHibernate.Spatial.Metadata.MetadataClass.SpatialReferenceSystem ); I get an error
Resource not found: NHibernate.Spatial.Metadata.SpatialReferenceSystem.MsSql2008GeographyDialect.hbm.xml
but looking into the library System.Reflection.Assembly.Load("NHibernate.Spatial.MsSql").GetManifestResourceNames() we can find:
"NHibernate.Spatial.Metadata.GeometryColumn.MsSql2008GeographyDialect.hbm.xml"
"NHibernate.Spatial.Metadata.GeometryColumn.MsSql2008GeometryDialect.hbm.xml"
"NHibernate.Spatial.Metadata.SpatialReferenceSystem.MsSqlLegacyDialect.hbm.xml"
"NHibernate.Spatial.Metadata.GeometryColumn.MsSqlLegacyDialect.hbm.xml"
Why the logic seeks for missing resource?

package
NHibernate.Spatial.MsSql version="4.0.3.4000"

Hey ppl !
When we can expect a compatible version with Nhibernate 5 support?

For MySQL57 and PostGis20 dialects, some tests such as ConformanceItemT23Linq fails because the returned geometry is null. The HQL variety of the same test (ConformanceItemT23Hql) works fine.

Most of the MySQL tests and some of the MySQL57 tests fail (see here for a list).

One of the main reasons for the failing MySQL57 tests is a bug in the MySql ADO.NET MySqlGeometry type when creating an empty geometry collection (see bug report here).

I'm not sure how to go about fixing the MySQL tests though? It's somewhat related to #80 and #83, but any help would be appreciated :)

When registering the spatial functions, the PostGIS dialect does not add the ISO prefix "ST_". This prefix was present for some functions prior to PostGIS v1.5, but was added to all of them in 1.5. At the same time, the non-prefixed ones were deprecated, with the view that they would be removed at a later date (link):

PostGIS has begun a transition from the existing naming convention to an SQL-MM-centric convention. As a result, most of the functions that you know and love have been renamed using the standard spatial type (ST) prefix. Previous functions are still available, though are not listed in this document where updated functions are equivalent. The non ST_ functions not listed in this documentation are deprecated and will be removed in a future release so STOP USING THEM.

When PostGIS v2.0 was released, they were indeed removed (link):

Most deprecated functions have been removed. These are functions that haven't been documented since 1.2 or some internal functions that were never documented. If you are using a function that you don't see documented, it's probably deprecated, about to be deprecated, or internal and should be avoided. If you have applications or tools that rely on deprecated functions, please refer to Q: 3.2 for more details.

The reason I discovered this was that nearly all of the PostGIS tests were failing using PostgreSQL 9.4 x64 and PostGIS 2.1. Is this a known issue?

In order to support PostGIS 2.x, I added the prefix to those functions (I'll be submitting a pull request shortly). However, what this means is that the minimum version of PostGIS supported would change to 1.5 (1.4 may still be somewhat supported as some of the functions already had the ST prefix in that version - would need further testing). However, given that 1.5 is six years old now, I don't think that's too unreasonable. Thoughts?

Thanks to IvoD for finding this bug.

I have replicated IvoD's issue using NHibernate.Spatial.PostGIS 4.0.4.4001. My entity class and FluentNHibernate mapping are as follows:

public class Entity
{
    public virtual int Id { get; set; }
    public virtual LineString Geom { get; set; }
}

public class EntityMap : ClassMap<Entity>
{
    public EntityMap()
    {
        Id(x => x.Id);
        Map(x => x.Geom)
          .CustomType<PostGisGeometryType>()
          .CustomSqlType("geometry(LineStringZ)");
    }
}

The test code to attempt to insert an entity with a 3D LineString:

var line = new LineString(new[] { new Coordinate(0 1 2), new Coordinate(3 4 5), new Coordinate(6 7 8) });
var entity = new Entity { Geom = line };
using (var transaction = session.BeginTransaction())
{
    session.Save(entity);
    transaction.Commit();
}

The SQL emitted by NHibernate is as follows (tidied for clarity):

UPDATE entity SET geom='0102000020346C0000030000000000000000000000000000000000F03F0000000000000840000000000000104000000000000018400000000000001C40';

which results in the following error:

Npgsql.NpgsqlException: ERROR: 22023: Column has Z dimension but geometry does not

Indeed, if we run the following SQL query:

SELECT ST_AsText('0102000020346C0000030000000000000000000000000000000000F03F0000000000000840000000000000104000000000000018400000000000001C40');

the result is:

"LINESTRING(0 1,3 4,6 7)"

so we can clearly see that at some point along the way, the Z dimension has been stripped off.

The stripping of the Z values happens in the PostGisGeometryType.FromGeometry() method when using the PostGisWriter to convert the geometry into WKB format. This is because the HandleOrdinates property on the PostGisWriter defaults to Ordinates.XY.

The fix for this is to specify the HandleOrdinates property on the PostGisWriter prior to calling the Write(geometry) method based on the dimension (cardinality?) of the geometry being serialized. I'll submit a PR shortly.

I'll also have to investigate whether the PostGisGeometryType.ToGeometry() will need to be correspondingly updated...

Hi;
I want to use NHibernate Spatial With Oracle, Can I ?
Thanks

just updated nhibernate to 4.1.1 and noticed that our geometry is not loading. Saving the geometry is working. After downgrading the lib, everything is working again. Anybody else having this issue?

Hi, I had to upgrade NTS and GeoAPI to their latest versions.
The "bindingRedirect" policy, applied to the library GeoAPI, not work and the library loading process keeps searching the 1.7.2 version (caused by NHibernate.Spatial.MsSql2008).
Are you planning to update these references in the short term?
Regards.

The connection string for the MsSql2008 test project specifies Type System Version=SQL Server 2012. When testing against a MS SQL Server 2008 instance (with 2012 also installed on the same system), this will result in many tests passing, when in fact they should fail due to non-support in 2008.

For example, the spatial aggregate functions were only added in 2012, so most of the MsSql2008ProjectionsFixture.* tests should fail when in fact they pass due to the use of the 2012 libs (see the documentation for the Type System Version connection string argument).

On my PC, changing the connection string to Type System Version=SQL Server 2008 increases the number of failing tests from 8 to 51.

When testing most of the time seems to work, but for large geometries I got an exception:

2016-02-17 18:19:15,645 [40] WARN  NHibernate.Util.ADOExceptionReporter [(null)] - System.OutOfMemoryException: Array dimensions exceeded supported range.
   at NHibernate.Spatial.Type.PostGisGeometryType.ToString(Byte[] bytes)
   at NHibernate.Spatial.Type.GeometryTypeBase`1.DeepCopy(Object value)
   at NHibernate.Type.TypeHelper.DeepCopy(Object[] values, IType[] types, Boolean[] copy, Object[] target, ISessionImplementor session)
   at NHibernate.Engine.TwoPhaseLoad.InitializeEntity(Object entity, Boolean readOnly, ISessionImplementor session, PreLoadEvent preLoadEvent, PostLoadEvent postLoadEvent)
   at NHibernate.Loader.Loader.InitializeEntitiesAndCollections(IList hydratedObjects, Object resultSetId, ISessionImplementor session, Boolean readOnly)
   at NHibernate.Loader.Loader.DoQuery(ISessionImplementor session, QueryParameters queryParameters, Boolean returnProxies, IResultTransformer forcedResultTransformer)
   at NHibernate.Loader.Loader.DoQueryAndInitializeNonLazyCollections(ISessionImplementor session, QueryParameters queryParameters, Boolean returnProxies, IResultTransformer forcedResultTransformer)
   at NHibernate.Loader.Loader.LoadCollection(ISessionImplementor session, Object id, IType type)

I am using postgres/postgis, running NHibernate version 4.0.4.4000 and NHibernate.Spatial.PostGis 4.0.4.4000.

my geometry in the db is not that big, it has 5104 points, which is 83672 bytes (82 kB).
Is there a limit on geometries? how can I handle big ones?
My system should support even bigger ones, the biggest I have at the moment is about 1664kB.

Any ideas?

I have been struggling for a few weeks when mapping my Geometry column in Postgis to IGeometry
here is a very detailed description of the problem

The solution in the end was to downgrade Npsql to use 2.2.7 and it just works.

I tried to report this to Nhibernate jira bug tracker but seems I am not allowed to, I might need to be logged in to their jira system in order to do so.
that is why I am reporting it here, maybe you guys can help me get this issue fixed.

Hi,

I am attempting to create a simple demo solution using NHibernate.Spatial.MySQL. The solution is available here: https://github.com/andrerav/NHibernate.Spatial.MySql.Demo

The mapping seems to mostly work -- the DemoDataImport project is able to read the GeoJSON files, and insert data into the database, and I can verify the results using MySQL Workbench.

However, if I query the data, geometries always show up with null values. Furthermore, if I perform a query such as this:

var municipalities = SessionManager.Session.Query<Municipality>().Where(m => m.Area.Within(county.Area)).ToList();

I get an exception that says "No persister for: GeoAPI.Geometries.IGeometry".

Any ideas what could be wrong?

To run the solution, first create a mysql database (mysql 5.7 or newer) called mysqldemo with username/password mysqldemo/mysqldemo. The DemoDataImport project will dump geojson data into the database, and the DemoQueryUtil project can be used to execute queries.

But my custom type is Serializable

I'm currently in the process of setting up my local PC (and also Appveyor CI) to run all of the test projects and it's not clear to me which versions of databases/extensions each dialect supports/is targeting?

I've put my best guesses in the table below and highlighted the ones I am unsure about. Does this look sensible?

Various spatial relation functions are missing the ISO prefix (ST_). This causes MySQL to use Contains() instead of ST_Contains(), which is a different function altogether.

Using MsSql2008GeographyDialect

//OK: Coordinates of type GEOGRAPHY
var exportScript = string.Empty;
new SchemaExport(configuration).Execute(s => exportScript = s, false, false);

//NOT OK: Coordinates of type TINYINT
var updateScript = string.Empty;
new SchemaUpdate(configuration).Execute(s => updateScript = s, false);

public class PolygonEntity
{
	public virtual Polygon Coordinates { get; set; }
	public virtual int Id { get; set; }
	public override string ToString()
	{
		return $"Polygon#{Id}";
	}
}
public class PolygonClassMap : ClassMap<PolygonEntity>
{
	public PolygonClassMap()
	{
		Id(polygon => polygon.Id);
		Map(polygon => polygon.Coordinates).CustomType<Wgs84GeographyType>();
	}
}

How can I generate an update script?
Do I miss something?

Currently the NuGet package for NHibernate.Spatial is stuck on version 2.2.0, whereas the sub-packages (MsSql, PostGis, etc.) are all on version 4.0.3.400. Is there any reason for this?

It means that in order to use NHibernate.Spatial functionality introduced since 2.2.0, you have to reference one of the sub-packages, even if you do not need any of the specific functionality from that sub-package.

Hi,
any chance to get an update for NHibernate 4.1 on nuget soon?
Thanks :D

I'm working on adding SpatiaLite support for NHibernate. In the process of getting the unit tests to pass, I noticed that there is an offset in the argument indices between the Hql and Linq test functions. Is that intended?

The tests

• ConformanceItemT23Linq
• ConformanceItemT29Linq
• ConformanceItemT31Linq
  only pass for spatialite, if I adjust the indices to those of the Hql counterparts.

This makes new features of MsSql2012 such as sequences, limit and iff unavailable when using a geometry type

NtsTestCasesFixture.cs has a reference to Open.Topology.TestRunner which I cant seem to find as a package.

Hi Guys,

We are pleased to call you to join @nhibernate organization at GitHub.

To make both 2008 and 2012 easily testable on a single 2012/2014 server instance, these dialects need different test projects.

When running against an azure sql database, all the geometry instances are always null when they're read out of the database.

Hi everyone,

I am delighted to see so much activity and progress being made on this project these days! I would like to propose that we create a discussion forum where we can discuss further development without the constraints of creating issues.

Some alternatives off the top of my head:

• Google Groups
• Discourse
• Gitter
• Slack

Suggestions and ideas are very welcome. I will close this issue when we have settled on an appropriate discussion platform.

When I try to save the geography:
"Column "adr_geography" is a type of geography but expression is of type text"

ErrorSQL:
UPDATE dbo.adres SET ADR_GEOGRAPHY = ((E'0101000020000000000000000000004E400000000000003440')::text) WHERE ADR_ID = ((34)::int4)

Code:
address[0].Geography = new Point(60,20);
transaction.Commit();

I've tried to update an app using nHibernate 3.3.3 to instead use 4.0.0 but I'm getting an error about being unable to find a field in NHibernateUtil (forgive my lack of an exact error, I tried this yesterday and have since rolled back) and the error is originating inside of the Spatial library. I grabbed the source from sourceforge for the spatial project, but it's not compiling for me within Visual Studio so I'm not positive where the problem is. The official change log for nHibernate lists something about a potential breaking change "Static fields on NHibernateUtil are declared as their exact class". I'm assuming this is the cause of the error in the Spatial code but I'm not sure.

Any chance of getting an updated build of the Spatial libraries to account for the changes in 4.0.0?

I implemented the ToGeometry static extension methods for Linq.
In the UnitTests where these functions play a role (the ones attributed Ignore("implement ToPolygon") I see that the IGeometry instance is being passed as parameter to the qurey and not being converted to the db specific type. Therefor the tests fails.

Is there a way to instruct NHibernate to convert the parameter prior to passing it to the query?

Hi

I have been trying to setup nhibernate spatial for the past days with little luck.
The help links in the readme file for the configuration and mapping don't point to any existing page.
So I had to google and found a really old page (2009) [http://nhibernate.info/doc/spatial/configuration-and-mapping.html] but with those settings I was not able to have it running. I get null on my geometry property.

Any help/links to help me get started would be really appreciated.